IMPORTANT: discuss midiCC => qreal/qlink data

Regarding 2kXL:

I have to fess up. I had heard a few people talking about MIDI control of the internal mixer and because of this assumed it existed, but back when I actually used a 2kXL I never tried it since the stuff I was doing at the time had no use for that function. I just looked at the manual and the only thing I can find that's even close to that is a toggle to switch reception of CC#7, though it's not completely clear to me if that's global system-wide only or something that can be applied or filtered to specific programs. Either way, I can't see any way of accessing individual program mix parameters via midi -- unless there's some secret SYSEX chart somewhere that I haven't seen yet.

BTW Antonym -- though most stuff is implemented to standard midi these days, SYSEX wasn't all before your time. The DSI Evolver still uses it extensively, both for memory backups and realtime control of internal functions.

Since this thread is about controlling the MPC 1000 with standard midi messages, the subject of using SYSEX to do the same is sorta off-topic, but I'll say this: Go for standard MIDI before even thinking about that. Implementing SYSEX on the MPC would probably require a major overhaul to the software, and even if this was done there's just too many SYSEX receive and transmit incompatibilities between different manufacturer's gear.

as always, an enlightening post.

this thread is great - I am imagining having 16 sliders and twisting the schit out my patterns, with keygroups things moving pitch, filter, panning, levels things could get very wild indeed... and recording the whole deal, could be a great development

O

i'll be sending the current discussion to jj soon. if necessary, i can send more but let's see if we can hammer out a simple "concrete example," which he asked for.

can we agree for starters we'd like to be able to assign multiple incoming midi ccs to all qdata: qrealtime, qnote on, and mixer?

the idea being to have an external midi controller (keyboard, midi mixer) w/ multiple knobs and faders controlling our qdata. it's like having many, many qlinks sliders.

Nym wrote:sootyG that's a very good idea, but it introduces so much new specification...ie what notation would that be recorded in? qlink, qreal, something completely new?

you're right: jj most likely would have to add a new category or specification to get all that stuff recorded. but would that really be that hard? think of all that jj had to add with all the adsr & keygroup stuff, and the code is still only around 920k or so. it looks like he's still got a lot of room to work with.

the other solution would be to have qlink & qreal recorded as it is currently, but have all the other stuff remain non-recordable. while it would be nice to have it recordable i would be perfectly happy with it being just for live use. as long as all the midi assignments are saved in the PGM file then you're set. call up the program and you would have all of your controllers mapped and ready to go.

think of having 16 sliders, each mapped to the sample assign of a pad. as your sequence plays you can move the sliders and change what sample is assigned to each pad and totally change the feel & sound of your sequence. that's not something i would necessarily want to record but it would be great to use while playing live.

also, cosign on the previous suggestion of having one midi controller able to control multiple parameters at once. this is like the 'morph groups' in the nord modular synth if anyone has ever used those. you can do some pretty powerful stuff with that.

Nym wrote:can we agree for starters we'd like to be able to assign multiple incoming midi ccs to all qdata: qrealtime, qnote on, and mixer?

definitely. that is a good starting point.

i would also let him know about some of our more far out ideas as well, tho. just to see what he'd think. i'm curious as to how much of that 'midi learn' idea i proposed he could implement, even if it was just for realtime use it would still be really powerful.

Nym wrote:can we agree for starters we'd like to be able to assign multiple incoming midi ccs to all qdata: qrealtime, qnote on, and mixer?

Yeah that sounds fine -- start with whatever the qlinks can do and just work from there.

It would help if the MPC had some way to differentiate MIDI intended for itself versus everything else. Channelizing is one way. Another idea might be to add a RECEIVE MIDI CC mode toggle to the MIDI/SYNC menu. One position for "normal" (cc received and recorded to track as is the way it works now), the other position routes all CCs to Qlink parameters. Perhaps a combination of both ideas?

yo, sorry if these were mentioned already:

Note repeat,
quantize,
and swing.

I'm dying to use this combo with my Kaos Pad.

this is so cool.

yeah sooty, i have included and attributed every idea posted that i've understood. hopefully while staying organized.

On adding a "learn" function --

Yes, those are nice but it would require a completely new section of code to be added. The quickest and simplest way to do it from the JJ perspective would be to just hard code the different CC numbers to the individual Q functions. There's a few hard-coded hardware controllers out there with fixed CCs or limitations on which CC numbers they can generate, but for most of the "real" controllers out there this isn't a problem.

I know some life-long soft synth junkies out there (definitely not me) might groan at the idea of manually configuring a hardware controller from a list of CCs but I personally don't have a problem with it since nothing I own has a learn function and I've always done it this way. In a way it's good -- you learn what messages you are sending rather than just selecting and tweaking and having no clue what the messages actually are.

your list of "to-be assignable parameters per channel" looks good, though i don't think REVERSE exists currently. i'd love a REVERSE parameter, as well as a PLAYRATE parameter. but again, first things first.

jj explained a non destructive reverse trick recently on his site...

mpc schould be able to send/record sysex data

sysex data are uncommon type of controls...for example i would love to use sysex to reach some parameters on my virus b or to record some presets in the sequence etc...

9>>midi soft take over or "analog" emulation

could you explain further?
sorry about my french
it's not nearly as good as your english.

soft takeover would allowed to forget midi parameters jumping (from this patch to another (this could be replaced by motorized fader (mackie control or bcf/bcr2000 plugged via midi
analog is what you see is what you get...

i'm sorry about my english, i feel some limitations in my explanations...

electric muz, that's true, that's TRUE. might experience a "cleaner" implementation of the feature if this is the case...

mkll, that's right, i remember the reverse trick now, that one is cool. this is a lot of stuff to think about, another big event

[quote="mkl..."]sysex data are uncommon type of controls...for example i would love to use sysex to reach some parameters on my virus b or to record some presets in the sequence etc...[quote]

Actually, you can do that already -- I've done it with the DSI box a number of times. There's just two limitations --

1. You cannot generate a SYSEX message from the MPC in realtime (i.e. from the Qlink controls). You can do it non-realtime from the MPC if you use the SYSEX editor function in Step Edit Mode, but in that case you have to know exactly what the message is byte for byte to program it in. Otherwise, you have to record the SYSEX changes from an external SYSEX programmer or the synth itself (assuming the synth has an option to send realtime SYSEX commands -- DSI does, not sure about Access etc.) Getting the MPC to send SYSEX in realtime would require a whole new SYSEX programming function to be added to set all that stuff up.

2. The MPC has to like the SYSEX that it's recording. This is a big issue with database-type midi recorders like the MPC. They just don't like some manufacturers' SYSEX implementation. You can try to record it in, but you either get nothing at all or (in the case of the MPC) some very strange sequencer malfunctions. On the other hand, some devices work without any problem at all. In terms of SYSEX functions, the DSI is perfectly mated to the MPC, and I've never had a problem recording or playing it back. I even upgraded the synth's OS once by just loading the upgrade file into a sequence and hitting PLAY... worked like a charm.. even I was surprised (though I wouldn't have tried that if my comp midi interface hadn't completely failed at the task..)

Okay so like I said this is sorta off topic so I'll stop now...

Im repeating myself here ,but can no one else see the usefulness of being able to asign midi note note numbers (on a specified channel) to track mutes?