IMPORTANT: discuss midiCC => qreal/qlink data

Sooty_G wrote:

formantuk wrote:LEARN FUNCTION-
1. put the cursor over a parameter & press the key combo SHIFT + NUMERIC
2. overdub LED starts blinking
3. move a knob or slider on midi controller
4. overdub LED stops blinking. assignment is complete.

any objections? is this the best way ?

just for the record, i prefer to have the cursor blinking as opposed to the overdub light going on during a midi learn. i associate the overdub light with sequencing and recording events, and that's not what you're doing here. also if you're looking at the screen or have your hands over the mpc it can be easy to miss that the overdub light is actually lit. better to have the cursor blinking since it calls your attention to what you're about to do.

how about both ? would that be agreeable - i think its useful if you also have flashing LED as it lets you know what mode it's in -

"cc control for loop start- and endpont would be good"

seconded, this would be a great feature, you could take a log sample and scoot about changing the loop position and length live - i miss this facility hugely on the MPC4k.....

O

what i'd really like to see is the ability to control a bunch of stuff simultaneously with one cc, like the decay of all the drums. that way you could use one knob to tighten up all the sounds at once.

^^I'd literally just signed in to request this. I was thinking something like Midi Notes Chanel 1 -> Pads
Midi Notes Chanel 2 -> Track Mutes
Midi Notes Chanel 3 -> Next Seq

This would mean that you could control the MPC from ANY DAW with midi out.

I've totally forgotten about the after keys, which are convenient when using the q links, any thoughts about how an equivalent could be implemented with MIDI ?... the more I think about it the more complicated this becomes!
maybe we could just have one global "after" key for MIDI and one for the MIDI CC on the active track?... thinking after keys for every parameter would be unrealistic.

Blinky.. im with the track mutes idea too (I mentioned it a few posts back)
I get the impression that people think its a good idea but the first focus is MIDI cc to Qlink paramters.If JJ wants to put it in now though i have no problem with that!
Being able to mute tracks without going into the track mute screen would be very cool especially for live MPC stuff.

1. I would like to see midi note in numbers assigned to track mutes e.g. midi in channel 16b(or any other) could be set to mute particular tracks without being in the track mute screen.

There are some good, and imho realistic ideas here, and a few ideas that are somewhat off axis from what the mpc is/should be.

Rounding up the given ideas so far, some CCs would apply to the general machine function, while others are related to the program or even individual sample/pad/editing functions. As a reminder: the MPC is meant to be a central sequencer itself, and as such aimed at controlling external midi hardware, not the other way 'round.
Imho really useful target for external control would be the track mixer:
-track volume. track muting being that CC at value 0.
-pan position.
And that's it. More may sound nice, but doesn't really make good sense.

What I don't see as useful: sample/pad specific parameters like start/end/envelope parameters/pad fx and such... they relate to a single sound/pad in a single program... the mpc can run more than one program at the same time, and those are not bound to specific midi channels either, but can vary from track to track... so... the only way to make such parameters a definite target of midi control would be to use sysex, and that's not a good thing to process within a musical content sequence cuz it will easily f*ck up the timing! sysex is not meant for realtime use!
it'd be a shitload of programming work, too. also, it'd only be accessible with controllers that are capable of sending defineable sysex strings, like the doepfer regelwerk. and I be damned if I start dialing sysex strings into my regelwerk to control the mpc. I want to make music, create, and not program my way to the stage. u kno what I mean.
peace
Joe

ps: if you need that much realtime control over specific parameters of specific samples, get a sample based synth. synth engines do that. drum samplers don't.

yeah agreed in many cases there, esp. re:pad specific stuff - not a good idea

really it should be track specific :ie - midi channel specific, so any program on a given channel should respond in the same way as it would on another channel.

then once there's a strong foundation set up to receive cc's :ie there's a solid and sensible control map to choose [source CC# > dest parameter] from - the realtime possibilties are immense...

lookin fwd to that.

btw : is os2 any real use yet, i mean how much bull***t is there to deal with.....ie: what doesnt work yet or has yet to be finished in terms of stable running - creation of progs/songs/tracks?

anyone.? - ive been dead busy workin, so ive been on trusty os1 499 all the time.

SirStony wrote:
ps: if you need that much realtime control over specific parameters of specific samples, get a sample based synth. synth engines do that. drum samplers don't.

i think uo've forgot some few machines : machine drum, electribe, mc 808, 909...

mkl... wrote:

SirStony wrote:
ps: if you need that much realtime control over specific parameters of specific samples, get a sample based synth. synth engines do that. drum samplers don't.

i think uo've forgot some few machines : machine drum, electribe, mc 808, 909...

yeah - but not forgetting that many of these great machines [elektron MM/MD for example] have very extensive midi control maps at their cores....

i doubt the JJOS is even going to get close to these designs.....its a humble device, with a far inferior cpu system i expect.

"if you need that much realtime control over specific parameters of specific samples, get a sample based synth. synth engines do that. drum samplers don't."


uhmm, but isn't the the whole point of JJOS2 is that it is not longer a drum sampler?

anything that enhances the 1ks abilties to be a performance sampler is great by me - that is why I bought it, I have never thought about it as just a drum machine

O

isn't the the whole point of JJOS2 is that it is not longer a drum sampler?

i agree with this totally, the OS is no longer defined by akais early 90's stipulations on what a drum sampler should be.

as as far as whats realistic etc etc it seems to me that MIDI cc should be first set to control what the qlink already controls (which includes individual pads,track, tempo,filters and all the rest we know and love.)
and the track mixer. I think Nym has already suggested this earlier in the thread.

FX settings can't be automated at all at the moment, so i would assume that these might take longer to implement, if at all for some of the details within the fx. Although it'd be great if they could. Even automating the FX send amounts would be very useful.

I think its good to start with the basics but feel that

sample/pad specific parameters like start/end/envelope parameters/pad fx and such... they relate to a single sound/pad in a single program

type control would be incredibly useful for manipulating beats, or in other words having a drum sampler when you can really control and play with the details of your drum programs.
I could imagine each CC assigned to a range of pads, similar to how we use the whole function in GPE. Another alternative would be to have CC groups (like the mute groups) and only the pads assigned to that group number will be altered by the incoming data.This option would mean that you could alter the settings of a group of pads which aren't necessarily adjacent.

anyway i'll stop rambling about possibilites and sum what i feel is most important:

CC to Existing Qlink parameters.
CC to Track Mixer.

mikolo wrote:Blinky.. im with the track mutes idea too (I mentioned it a few posts back)
I get the impression that people think its a good idea but the first focus is MIDI cc to Qlink paramters.If JJ wants to put it in now though i have no problem with that!
Being able to mute tracks without going into the track mute screen would be very cool especially for live MPC stuff.

Cheers man, I must have missed your post

mikolo - this is a really good idea: u said.....

"Another alternative would be to have CC groups (like the mute groups) and only the pads assigned to that group number will be altered by the incoming data"

i really like the simplicity of it, a bit like a 'cc patch group'....like in the emu's and bigger akai [Z8] - where a source and a dest are set up. in ur post u have nailed the source AND the dest routings in one page thats already familiar in build to the mpc community - so its a big thumbs up for that

i hop JJ sees that post!

cheers blinky and arebee,
Its cool that so many ideas get discussed hear and actually do end up being implemented. Being able to have some way of controlling individual pads or the whole track would be great and having control over a range of pads would be even better. Either way Im looking forward to see what JJ comes up with.