I have 8 drum-devices (M4L-Diy) on 8 Live-Tracks, per Device it has 64CCs (Live.dial)
a total of 512 Controllers then.
I do remote them with 1xBCR2000, in the past like that:
I select 1 Device with 1 of the 8 Device-Select Buttons (BCR Button row)(I call it a ID1-8)
So by pressing ID1 the output of the 64CCs of the Drum-Device are gatet (closed).
Now I "outputvalue" the Live.dials - these are routet to a "Send"
This send is receiving my Control-Patch - with its 64CCs that are maped to my BCR2000 (the output of my Patch are also gatet @ this update process, because "set integer" dont send CCs to my Device)
After Switching to Device to ID1, the above describet update (dump out from Drum-Device)is complete, and with a simular way it goes Back from Controller to Drumdevice (turning knobs).
----A other idea is to go with the UDP-Send@local host from MAX-Standalone-device into the Drum-Voice-Instances (inLive), and then change Parameters directley (and of course paralell - set the Live.dials without output --- same prinzip but outside live)
+ Positiv:
It works, also on +50CPU usage, Live dont crashes, no crackling
- Negativ:
The Switching between Drum-Tracks is slow, because I made them slow, deferlow´d and delayed, on small outputrate because elsewhere not all CCs are changed on my BCR...
So what are the alternative to get 8x64 MidiCCs out of the BCR2000 without pressing the PRESET-BUTTONs on the BCR? (which is not working in nearly every situation- if you can think you know why...)
One Thing is to use REMOTE~ and Live.object --- but 512 mapped parameters? I have crashes with 1x64 Parameters (by mapping the launchpad grid to some remotes and live.objects...) persistent remotes @ many controlls wont let me open the liveset - (crash on startup)
so 512 remotes @ 50%cpu usage (4x2,8GHz 12mb Cache DAW machine) will not work
Not work with persistent (save ID in object, and load @ startup)
May work with 64x8 Pathes that are triggerd to 1x64 Remotes - by switching them from ID0 to IDPathwhatever. But changing Pathes in the liveperformance is a risk, i had much problem by crashing some API thing, that afer a while I cant remote anything in the whole set (reboot the Set!!!).
+ good concept
- not good in Reality > crash, stability, wont open set, cpu-usage....
So what then?
Maybe MaxStandalone which simulates 8x64 MidiCCs - connected to one Real MidiController (BCR2000) > A CC Buffer > connect via Midiyoke or "loop midi" 2 live and back...
Thats the easiest way I see > but what happens when I map 512 Parameters - what happens on live-startup , or by changing some midisettings in live (maybe again a crash?)
Thats what I will try because I know how, and I own a maxstanalone-license.
But whats with Ableton Remotescripts?
The Launchpad95 Script, give us extra Midiport for CC input - so it is possible with a script also send data to a midiport > so I can midimap whith these.
But whats with a BCR2000 - not much script out there which do what I want (a simply 8x72 CC-Bank/Controller)
I dont know that - a idea: I think that I cant get access to my diy M4L-Drum-Voices wich such script (isn´t it?) I can get to DAW parameters and Built in Plugs...
The Ideo of APC and Track-Select-Buttons - is to observe and get values from them? so there is no Buffer between - this is api-"realtime" ?
So a Buffer of saving MidiCCs in a Remotescript is not there? A buffer which Dumped out to my BCR2000 by pressing a Dump 1-8 button is´not possible? (without touching into live?)
So any other Ideas? Maybe a BCR2000 firmwarehack
I got my first BCR2000 @ 2005 2006? dont know years ago... and i always had spendt much time on it (encoder resolution, hex, birdie, cutting Overlays, sticking Brother-P-touches, cnc drill overlays, let them fall to ground, repair them if possible and so on... but the preset thing of much MidiCCs? Pfffff I dont know the Ideal Solution has not com, did not found, did not done or whatever my aaarrrrg gramatic English can say...
)HMM- Some good IDEAS? Is that True, what is False of what I have said....
I just won´t start to program a divece a way that would not work @the end because of "Bigness"(512CCs!!!)
- sounds good - good enougth to give it a try