Comments by T0n1
The Attach button triggers that synchronization manually. By mapping it to a button on the controller, you can even switch between layers of mapped VSTs within the same Live Set. See e.g. Part 2 of my tutorial series (there I'm using the VST instead of the AU version as it needs no manual triggering) at:
https://vimeo.com/96426685#t=482
https://vimeo.com/96426685#t=482
The device itself is useless outside the context of the Live Set from the download URL with its Audio and MIDI Test Route. I developed it after experiencing unexpected latency with M4L device chains, as opposed to internal devices like Utility.
I'm still on Live 8, but if I remember correctly, the "Live Sets that contain Max for Live devices or third-party plug-ins now have lower latency" change introduced in Live 9.2 is said to have fixed that problem: buffer read/write cycles are no more performed sequentially on a single device-to-device basis for each cycle, but the whole chain is processed within one cycle, thus the latency for one device is the same as the latency for a multiple device chain - and the example Live Set contains exactly such a long chain.
But for measuring the internal latency of a plugin or the latency of external hardware, the tool should still be useful.
I'm still on Live 8, but if I remember correctly, the "Live Sets that contain Max for Live devices or third-party plug-ins now have lower latency" change introduced in Live 9.2 is said to have fixed that problem: buffer read/write cycles are no more performed sequentially on a single device-to-device basis for each cycle, but the whole chain is processed within one cycle, thus the latency for one device is the same as the latency for a multiple device chain - and the example Live Set contains exactly such a long chain.
But for measuring the internal latency of a plugin or the latency of external hardware, the tool should still be useful.
I could only check on Live 8.4.2 for lost mappings, e.g. with the ./Tutorials/Part 2 - Patch Rack Presets.als example, and I can reproduce the observed behaviour partially. First of all, I usually map directly to AU/VST parameters, too, instead of going through Macro controls. Second, not all plugins behave the same with parameter feedback, if the VST doesn't work, the AU variant might do.
The BCR2000Control devices incorporate the concept of temporally detaching the selected device (mainly for blue hand override or for manual parameter changes in the Ableton GIU, as they get disabled when attached): If the synth *device* is selected (its title bar turns yellow), the "Detach" button(s) of the controlling BCR2000Control devices flashes red to indicate that it is no more in control until another device is selected.
It is important to note that selecting a rack *chain* doesn't affect the selected device: You can select the synth in Chain 1, select Chain 2 and view the flashing Detach buttons there, as the synth is still selected. Select e.g. the BCR200Control device in Chain 2, and the Detach button stops flashing, as the synth has been deselected.
Changing a preset in the VST preset dropdown within the Ableton GUI or opening the VST/AU GUI and changing the preset there doesn't necessarily involve *selecting* the device (which would temporarily detach ist), but even if I take care *not* to select it, e.g. with the VB3, there is a difference: Presets changes in the dropdown in the Abletion GUI get fed back, but preset changes in the VB3 GUI not - but direct parameter changes in the VB3 GUI nevertheless get fed back. But this behaviour is specific vor VB3 on OSX, other plugins behave differently.
The BCR2000Control devices incorporate the concept of temporally detaching the selected device (mainly for blue hand override or for manual parameter changes in the Ableton GIU, as they get disabled when attached): If the synth *device* is selected (its title bar turns yellow), the "Detach" button(s) of the controlling BCR2000Control devices flashes red to indicate that it is no more in control until another device is selected.
It is important to note that selecting a rack *chain* doesn't affect the selected device: You can select the synth in Chain 1, select Chain 2 and view the flashing Detach buttons there, as the synth is still selected. Select e.g. the BCR200Control device in Chain 2, and the Detach button stops flashing, as the synth has been deselected.
Changing a preset in the VST preset dropdown within the Ableton GUI or opening the VST/AU GUI and changing the preset there doesn't necessarily involve *selecting* the device (which would temporarily detach ist), but even if I take care *not* to select it, e.g. with the VB3, there is a difference: Presets changes in the dropdown in the Abletion GUI get fed back, but preset changes in the VB3 GUI not - but direct parameter changes in the VB3 GUI nevertheless get fed back. But this behaviour is specific vor VB3 on OSX, other plugins behave differently.
I've encountered a MIDI send/receive congestion problem also when heavily using the device(s) as a Wah Wah with a foot controller. Live 8 doesn't seem to be able to catch up with the audio buffer in that situation and Live's CPU meter remains stuck on high percentages. Thus although everything is programmed for separating the high priority real-time thread (from MIDI in) within the BCR2000Control device, I've put up a BCR2000IO-lowprio.amxd alternative in the download folder which seems to behave more gently. Still unsure whether I should enforce the low-prio thread or make that an option for a future version.
Version 1.2 has an enhanced parameter feedback conduit: Prior versions sent the current Ableton parameter value back to the BCR2000 hardware only when attaching to device parameters, but with 1.2 it uses live.observer objects to immediately reflect parameter changes made e.g. on a VST/AU GUI back to the BCR2000 LED rings.
But according to your problem description, your setup may suffer from a known BCR2000/USB/driver/? instability problem: Sometimes MIDI CC messages aren't transmitted to the hardware for whatever reason, for more details see the comments on the 1st tutorial video at http://vimeo.com/t0n1/bcr2000control-1
What happens in that case is that it jumps to the value that happened to be visible on the LED ring of the knob before instead of the actual parameter value which should have been fed back when attaching.
But according to your problem description, your setup may suffer from a known BCR2000/USB/driver/? instability problem: Sometimes MIDI CC messages aren't transmitted to the hardware for whatever reason, for more details see the comments on the 1st tutorial video at http://vimeo.com/t0n1/bcr2000control-1
What happens in that case is that it jumps to the value that happened to be visible on the LED ring of the knob before instead of the actual parameter value which should have been fed back when attaching.
The first part of a video tutorial is now online at
http://vimeo.com/t0n1/bcr2000control-1
http://vimeo.com/t0n1/bcr2000control-1
"Teach in" as in "teach-in-robot": Instead of programming it using "move to position 125.0/77.5" put it in learn mode an move it to that position using a controller.
In DrumSeq/Notemap terms: instead of "Pitch settings -> Row 1 -> Note 1 -> set the value to C1" just hit that note pad on the Launchpad or a key on an external instrument.
In DrumSeq/Notemap terms: instead of "Pitch settings -> Row 1 -> Note 1 -> set the value to C1" just hit that note pad on the Launchpad or a key on an external instrument.
https://youtu.be/WDhKuXn-yPo