Hi all,
when I subscribe to feedback I get a lot messages which I can use to create/update my surface. However I did not find explicit messages if a track gets deleted or if I unselect a track.
I also did not find a proper way to infer this from a “missing” message because an update is not atomic.
The only option I see is to query Ardour on every feedback message, however that reduces a lot of overhead.
Has this been considered in the design?
FYI Banking is disabled
If a track gets created or deleted, you will see new track names for all tracks. If you use /strip/list at all, you will get a /strip/list from Ardour if the list of strips changes. It was generally expected that /strip/list would be used with surfaces that do not use banking. If a track is unselected/selected then that track should send a /strip/select ii ssid select_status.
A more complete idea of how you are using OSC with Ardour would A) give me a better idea of how to help or B) give better ideas of the direction OSC control could go. So far the direction that OSC control has gone has been determined by SW/HW that is available or being written. Such things as TouchOSC or Open Stage Control and a few dedicated controllers.
I am developing a hardware controller for Ardour. This includes channels using BCF2000 (I bridge midi to OSC on a raspberry pi) and one single channel strip (eq, compressor…) which is for the selected track. Whenever a track is selected the hardware should go through all plugins and find eq and compressors that it has mappings for. If a track gets unselected the channel strip should be disabled.
I use https://github.com/scgolang/osc for OSC which does pattern matching.
For the channel strip, can you give an example what queries I should send and which responses I can expect.
I use Ardour 5.10
The control surface I have in mind is inspired by an LS-9. You have 32 fader, each has a mute and select button. This sounds like a job for BCF2ks because they are cheap and have exactly this physical setup. In a prototype I will probably connect them using MCP or without any at all, but since I use OSC anyway (see next section) I want to drive the whole surface with a single protocol.
Having knobs for eq, compression,… in each channel would be to expensive, so I have one eq and compression section with dedicated knobs for Q, Freq, Level…
Those control the currently selected channel. And if there is no selected channel they shouldn’t do or show anything.
A track/bus can have various plug-in. My assumption is that each has 0-1 eq’s + 0-1 compressors. Technically there can be different plug-ins for eq’s so I plan to have configurations for a couple of plug-ins that map parameters to knobs. Therefore, I need to get the list of plug-ins for the selected track and filter for those that are supported.(by hardware I meant the control surface (outside of Ardour))
After I have eq and compressor running I want to build surfaces for other plug-ins I use, so I use custom hardware for that.
Hope that clears it up 
Let me get this right. You are only using the BCF2k as a smart strip to control plug-ins. So to me this means the whole BCF2k would control only the plugins on one strip. The selected one. Then you go on to say: “Whenever a track is selected the hardware should go through all plugins and find eq and compressors that it has mappings for. If a track gets unselected the channel strip should be disabled.” This sounds strange in the above context. Now it sound like you want to use a fader, encoder and a few switches to fully control eq (24 controls for a-eq) which sounds difficult at best. This also makes me wonder if you expect to be able to also still control level, pan, rec, mute, solo and selection with the same strip? Generally one strip at a time is selected, so a strip is unselected by selecting another strip. using the /select group of OSC commands expects this to be so. The idea that the hardware would go through plugins and select something does not seem right either, this sounds like a software job your Pi could tackle. (I would use liblo for sending/receiving OSC btw, most of the other libs seem to have problems. If you have your Pi loaded with a debian based OS liblo is just an install away)
So anyway, if anything, I am more confused now than I was before. (the BCF2k works quite well with Ardour’s MCP code BTW)