atomictag

yes, put it on the master track (any other would do too, really, but it's more logical to keep it there). And yes it's more useful when you have more than 8 tracks. Hope this helps

Great device. Thank you for this. A few minor features could be added:
- MIDI tru toggle. It's great to mix random hits from this device with a MIDI pattern in a clip. Great esp with drums.
- Visual update of scale notes also when the scale is changed (AFAICT highlighted notes change only if the key is changed). Perhaps this could be done so the current values are preserved instead of maxed-out on change
- An additional visual indication of which notes are "hit" by the random assignment even when they are not played (because weight is too low). It is indeed not obvious which notes are picked by the random assignment which IMO is nice to see.

Anyway, great stuff - really enjoying it

@EugeneLaurence check out http://www.maxforlive.com/library/device/2238/move-clip-grid-launchpad-push-move-red-box I think that's very close to what you're after. cheers.

Hello there,
Thanks for your feedback.
Yes, the automation part is a bit of a pain (wished M4L allowed to choose what to include / exclude from automation). I have been trying unsuccessfully to find ways to prevent the CC MIDI automation from being recorded. M4L allows to delete clip envelopes for specific parameters and that work reasonably well (I used that in this little patch http://www.maxforlive.com/library/device/3515/track-select). But since MIDI data has no "id" there seems to be no way to do that for recorded CC automations. So usually I resort to keep the CC automation and delete the parameter automation - but that of course requires the device you are controlling to be specifically built for this purpose - or manually delete the MIDI automation after recording (which of course is a no-go for live situations). Hope this clarifies things somehow - sorry I could be more helpful

I have purchased LaunchSync PRO from Isotonik and while it's a great (and super recommended!) product - with great extra features - it did not fit my purpose (incl. the fact LPC Live 2 is not supported by LaunchSync).

So yes, similar idea.

For clarity's sake - there is no connection whatsoever with the actual LaunchSync M4L code (that's something easy for everyone to double check, btw). I am sharing this because I have done it for myself - and think others may like it or want to rip it apart and improve it.

@braduro thanks for your questions. Admittedly this device is not the easiest to understand, I guess. The idea is simple, though:

- You have a MIDI controller sending CC messages to LIVE ("Track In" enabled in Preferences)
- You have one or more instances of this device in each !!MIDI!! track where you have devices that you want to control with the CC messages sent by your controller
- Now go on and map each device to the parameters you want
- For each mapping set the CC number that will control it

Now when you !!!ARM!!! a track (containing one or more control bank instances) and twist the knobs, you'll be controlling the parameters mapped on the control bank device(s) in that track.

When you switch track and !!!ARM!!! it (assuming the previous one is disarmed) now you'll be controlling the parameters mapped on the control bank device(s) in that track.

That's the basic idea: route CC into the control bank however you can/want and change the parameters mapped to that CC.

New update 3.0 brings a completely rewritten code and a major overhaul of functionality and stability. Hope you'll enjoy it :)

Thanks for your feedback.

Actually I have a new version in the works completely rewritten that is a lot more reliable and with a much better takeover function. I'll post that as soon as I clean things up a bit.

@stilleto yes, only channel 1. That's a limitation (or a feature?) of Live. Basically MIDI channels are available in Live only for routing and MIDI-mapping. Within a channel strip each and every midi message - notes, CC, PC etc. - have always channel 1, no matter what. That's a bit of a nuisance for this device because this means you need to carefully assign the CC values to your hardware knobs and buttons in case you use multiple controllers at once in order to avoid collisions (or use a couple of spare buttons to enable/disable devices etc.).

thanks for the feedback, much appreciated :)

I wanted to revamp this device at some point with some extra features like the one you mentioned - which shouldn't be too hard, really. As soon as I get a bit of time I will definitely update it, so stay tuned

There you go. Try out 2.1 Things should work fine now.

True. It happens only the first time a parameter is mapped, AFAICT (if you modify the target parameter after it's been mapped it works as expected). Will investigate this further, tho

I have uploaded a new build - pls try that to see if it fixes the issue of the device not working as it should.

Thanks for the good feedback, will add quantization at some point (soon). I was thinking about something like:

- You can choose between "free" and "quantized". "Free" will work as it does now, i.e. you set the time, start is immediate, transition interval is proportional to the actual delta between current value and max value. "Quantized" will always start the transition at the next bar (or should that be configurable as well?) and you can choose how long (in beats/bars) the transition between current value and max value will be.

Would that be ok?

Yeh, was thinking about adding synch'd values at some point and maybe some fancier ramps with some kind of easing in/out between values.

Glad you like it :)
Stay tuned...

Hi there. What you're trying to do is essentially the reason I made this device (all other feats like value scaling and transient mode were after thoughts). Now, I normally do what you want to achieve in 2 distinct ways:

1. Use a Midi router utility like http://www.maxforlive.com/library/device/3003/live-midi-router-and-receiver or http://www.maxforlive.com/library/device/3007/midi-router-and-receiver-xs (I use my own, but they all do the same thing) and then assign a hw knob to change the output "channel" while having a receiver in each track set to a different channel. This way midi messages reach only the devices in the matching track

2. Without any external device, I use a router track with monitor IN and input from my hw controller. Then I set the receiving tracks with monitor AUTO and midi input from the router track. Then I arm the track I want to process midi/cc messages and unarm the others. Voila. Only the armed track gets the midi data, so you can have one instance of my device in each track listening to the same cc message - only instances in armed track get the data. I tested this with a LaunchControl and it works fine. Of course you have to be careful in arming/unarming the right tracks, but most controllers allow you to do that pretty easily.

3. If your controller supports "pages", i.e. midi/cc messages sent to different channels (LaunchControl, LaunchPad..) you can have your tracks receive midi input directly from your controller, but on different channels. Live does the routing for you in this case.

Hope this helps

Would love to hear your feedback on whether Value Scaling takeover mode works with your setup. Also pls let me know if you find the v. 2.0 "Transient Mapping Mode" useful - I personally find pretty cool to be free to change parameters freely without the control being "disabled because it is controlled by a Max device".

I have updated the device to v 1.1 (there was a delay in Value Scaling takeover mode I used for debugging that was left in by mistake).