View Single Post
Old 12-01-2009, 07:55 AM   #110
Human being with feelings
Join Date: Aug 2009
Posts: 157
Default Getting track mute/solo state

I decided to port my BCR2000 control surface plugin for Sonar to Reaper. This has been very popular in the Sonar community because it provides quite extensive functionality (search for BCR2000 in for the project and documentation) and now I have Reaper I miss having that functionality. I'll contribute it to the stash when done, of course.

(note: the BCR2000 does NOT support Mackie mode unlike the BCF2000 so this is not an option for BCR users)

After a day or so of reverse-engineering the existing control surface SDK source I was able to modify my code to get the core part of it working, and what I am now doing now is taking the points at which it interfaces to Sonar and changing those to call, as far as possible, the corresponding functions in Reaper.

So far I've been able to get MIDI in and out to the control surface working, and I can programmatically set the MUTE status for a track from the control surface - so the core code is essentially working - but I have now hit a rock and can't figure out from the header files and sample code how you programmatically get a track's mute and solo status BACK from Reaper, because now I need to get the full duplex bit working i.e you toggle mute/solo etc from Reaper and the control surface updates accordingly.

I simply can't find an API that appears to retrieve a track's mute or solo status. What am I missing here?.

There seems to be APIs to get track pan, volume and all the FX parameters, as there are with Sonar, but mute and solo seem oddly missing.

Experimentally I tried calling GetTrackUIVolPan and indeed the values of volume and pan are returned correctly, so they're ok. It's mute, solo, and - come to think of it - record arm as well, for which there are SET APIs but apparently no corresponding GET APIs.

Also, I'm assuming that the model here is identical to Sonar in that Reaper will call the control surface every so often (I think 15Hz refresh is the standard) and that this occurs regardless of whether or not any settings have changed in the Reaper project. It's then up to the control surface code, as it would be in Sonar, to programmatically determine whether any controlled parameter on the surface has changed, Reaper doesn't call you back specifically when the user changes a parameter from Reaper itself, as far as I can see, is this correct?.

Finally, at this stage - though I may find other things as I complete the project - I'm not sure how to manage sends and busses programmatically. In Sonar, tracks have types - standard, master and buss, and you can interrogate or set any of their properties. In Reaper there seems to be just a single master out even if I define multiple hardware outputs and I'm not quite clear how to programmatically control this - what track number, if any, would the master have?.

As for sends, I haven't yet explored the FX APIs but is Reaper treating sends as part of the FX chain programmatically or separately. I couldn't see anything obvious in the SDK APIs for this.

I think it would be a very good idea to document the SDKs, to be honest, because it would really help third parties to develop added value for Reaper. At present it is proving rather challenging to reverse-engineer from the very sparsely-commented sample code. However, I would really appreciate any clarification or assistance that you can provide; I'd love to get this ported over and I think Reaper users would find it useful.
ajaym is offline   Reply With Quote