IMPORTANT: discuss midiCC => qreal/qlink data

mikolo wrote: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?

There are a few pieces of gear that have a special mode wherein every digital front panel control can send and be operated remotely by an assigned note number. One note for switches and two notes for up/down variables. This can be extremely useful and elegant solution since it doesn't require implementing any weird or exotic protocols (like SYSEX or NRPN). You just can't have more than 127 controls, obviously.

It's slightly removed from the subject we're talking about here, though.

..also MIDI in to program change.
i haven't mentioned this before. it's cool that you can change seq by program change messages, but shouldn't there be a way of changing programs themselves by just one or two buttons up or down? It can be a little cumbersome to do this at the moment i.e.locating the right part of the screen and using the jog wheel..certainly more so than your average keyboard which you can play and change the patch very easily....for me one of the major points of the MIDI IN q parameter is to make the MPC more playable.. imagine changing to an adjacent pgm with slightly different pad assignments.. from on the fly mutes of individual pads to a wholesale switch of the sounds...
again something that i reckon has loads of potential but seems easy to implement.

One note for switches and two notes for up/down variables

ha ha is mind reading somewhere in the MIDI protocol too? :

shouldn't there be a way of changing programs themselves by just one or two buttons up or down?

seriously though .. is that so far off topic? I see this as about MIDI in control of the MPC, i appreciate there is a difference between CC and NOTE off/on.

Also we only have 64 tracks, so one MIDI channel out of 32 (user defined) can cover this easily with every MIDI note number and leave enough spare for 64 ttracks of the simult program! cause 0 is a value too isnt it?..(now i am getting carried away!)

the simplest way i can see of implementing this - would be similar to sooty_g's idea.
but without all the extra code.this way would be simple and code efficient.

this way theres not a rats nest mixing it with existing midi stuff and what not.

midi learn mode.

example

1. go to the learn mode option - say: [MODE PAD9] F4 learn tab
2. have a list with all parameters in it
3. when you find the parameter you want press the overdub key
4. the press or move your controller to assign.
5. the overdub light goes out all done, thats it.
repeat for all other controllers.

mikolo wrote: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?

this would be cool.
i'd settle for just being able to assign track volumes in the mixer to controller knobs, though.
there's lots of times i'd like to be able to fade a track in or out instead of just mute/unmute, and without going to mixer screen and cycling through tracks.
the way the mpc is set up, where you can only control the program on the active track via midi, would we be able to control multiple track volumes that might use different programs simultaneously? or is that just wishful thinking on my part?

i would prefer to have the cc to track level

cc control for loop start- and endpont would be good. also if loop lenght locked in trim mode = control start and end point together!

this would be perfect for creatvie loop mangling!

i would prefer to have the cc to track level

yes me too if its an either/or thing, track mute note in could be a useful addition at later stage perhaps.

Also It 'd be good if MIDI in q parameters could be assigned to a group of pads rather than just indivdual pads or the entire track.

Also It 'd be good if MIDI in q parameters could be assigned to a group of pads rather than just indivdual pads or the entire track.

exactly
which is why the beginning of this is basically being able to assign midi ccs as if they were up to 127 extra qlink sliders...unrealistically speaking, there are 127 functions which could be assigned.

i'm with muz when he suggests hardwiring ccs to the existing qdata, using ccs all in a row. that still leaves what, more than 100 recordable ccs to be assigned to other parameters - existing and new - by future request.

it would be nice define what kind of controller we will use with the mpc so we could define simples and straight ways for parameters assignations.don' t you think? what's your midi controller?(later we wil share our midi patchs for differents controllers)

motorized fader/rotary controller, else...?

i'm probably gonna buy a bcf 2000 which can be used as a mackie controller.
mackie controls are a kind of reference : faders for tracks volume, rotary for pan or else (filters, effect etc...)
a mackie control kind of assignation would be dope

about the differents kind of assignations perhaps it will be easier to have a midi implementation chart available for 16 channels from 1 to 127:
1>>>track volume
2>>>track pan
3>>>track velocity(velocity is assignable to many parameters)
4>>> track filter
5>>>track pitch
...
127>>>etc...

edit i would love effect send via midi...

formantuk wrote:the simplest way i can see of implementing this - would be similar to sooty_g's idea.
but without all the extra code.this way would be simple and code efficient.

this way theres not a rats nest mixing it with existing midi stuff and what not.

midi learn mode.

example

1. go to the learn mode option - say: [MODE PAD9] F4 learn tab
2. have a list with all parameters in it
3. when you find the parameter you want press the overdub key
4. the press or move your controller to assign.
5. the overdub light goes out all done, thats it.
repeat for all other controllers.

this is possible but i don't see how this would save JJ any work or be more code efficient than my suggestion. plus i imagine it would be really tedious to scroll thru the entire list of parameters (there could be hundreds) in alphabetical order every time you wanted to assign a controller. i would rather do the assign right in the screen where the parameter resides, since we already would have that location memorized. either way it's gonna be the same amount of code from JJ in setting up the infrastructure for this to work.

i've allways fancied having external ctrl of :-

fx parameters : change the fx sets - and the various values of parameters.

lfo rates & depth : in a local and global sense - all lfo's or just one.

sample fwd/rev play : program by midi chan, or all samples.

loop on/off : again by chan or all.

program filter values : by chan or global.

any ctrl by chan would be ace, say filter - by cc on the chan that the prog is on, global - i'm not sure if there could be an extra 'midi cc' tab Fkey in the 'midi/sync' pages where these basics are set - 'CCctrl : by chan/global'.

i also think it would be wise for JJ to use many of the pre-defined midi cc ctrl names as they were intended - some have specific (and appropriate) names, just to keep things quite clearly labeled and midi universal.

as it stands, os499 can record cc's, and they can be edited in the midi editor pages, but if so , does this mean in future any recorded cc's will be directly controlling the mpc's functions?

there needs to be some sort of distinction in coding - to avoid confusing the data where cc's are intended to be related to internal mpc events, and not to be recorded for playback via the midi outs to any outboard gear - as it is at the moment.

i think that in 99% of the time, the fact that there is no midi output assignment on internal-sound tracks controlled by ccs will be enough to differentiate which is which

but, as i see it, the cc itself would not get recorded but rather the appropriate qdata. also, this would apply to incoming ccs, not necessarily outgoing ccs.

Sooty_G wrote:
this is possible but i don't see how this would save JJ any work or be more code efficient than my suggestion. plus i imagine it would be really tedious to scroll thru the entire list of parameters (there could be hundreds) in alphabetical order every time you wanted to assign a controller. i would rather do the assign right in the screen where the parameter resides, since we already would have that location memorized. either way it's gonna be the same amount of code from JJ in setting up the infrastructure for this to work.

i think your idea is great and makes sense.
but how would you implement it?
what other keys or way would you use, to activate the learn function?

tell us more about how you would get it to work.