Control Surface SDK

Author
maxberg
Max Output Level: -90 dBFS
  • Total Posts : 17
  • Joined: 2008/12/06 17:40:46
  • Location: Austria, Vienna
  • Status: offline
2008/12/17 03:08:56 (permalink)

Control Surface SDK

Hey everybody!!!
Does somebody have a very basic example how to use the Control Surface SDK or a better documentation???
The problem is that the MotorMix example is too much information =)
I used the Wizard to created an emty project and I don't know how to start...


Thanks, thanks, thanks!!!
Max^^
#1

3 Replies Related Threads

    aj
    Max Output Level: -69 dBFS
    • Total Posts : 1084
    • Joined: 2003/12/08 08:21:36
    • Status: offline
    RE: Control Surface SDK 2008/12/17 06:28:27 (permalink)
    I feel your pain. It takes a bit of getting your head around and its a shame that the documentation is somewhat fractured; it goes on about stuff like state machines etc. which is not entirely relevant to the actual interfacing to the control surface.

    In addition, with all due respect to Cake, I would not have designed the SDK quite the way they did, particularly, I wish that you didn't have to poll for state changes and that Sonar called you back instead, but it does work, and I'm very grateful for Cake making it available. Also Bob and Morten were extremely helpful to me when I got stuck, you don't get that kind of support from most software companies.

    For some (reasonably well commented, IMHO) code that does not use all that fancy state machine stuff and is a fully working example, there is my BCR2000 control surface plugin code at www.sourceforge.net (search for BCR2000). I tried to use as little C++ as possible so it is mainly ANSI C and does not try and get too clever.

    Since the BCR is such a cheap unit, you could buy one second-hand, use the existing software and then take that as a fully-working solution and build your own derivative from it. The software is released under the BSD license which means you can do anything you want with it. You need Visual Studio for the control surface DLL and Visual Basic 6 for the UI - but the UI is completely separate and not required in a new implementation if you don't need any user interface for your control surface. Or you could build your UI in .NET, for instance, since the example code uses COM to talk to the UI as a separate process.

    If you are not a reasonably experienced C/C++ programmer this is still not a trivial task, of course, but it is doable. The SDK isn't that hard once you work out what's going on, possibly my code might help, at any event, best of luck!

    Couple of tips.

    1. It is easiest to use MIDI CC as the way to communicate state changes if your control surface can send those. NRPNs are more complex and there is not usually much advantage to using them

    2. If you do use MIDI CCs, start around 8. Sonar has an annoying habit of zeroing out everything with a stream to all devices on (I think) CC 0 or 1, can't remember, but this caused me some head scratching.

    3. Although this isn't entirely clear from the documentation, all MIDI events, regardless of channel, will come to the control surface plugin, for the device connected to its input. If you want to share this device with other MIDI devices, you will need to do channel masking in your code (which my code does).

    Otherwise its basically a case of receiving a MIDI event, and then changing a track parameter e.g gain, pan etc. All parameters are normalised to the range 0 through 1 as floating point numbers, so for a MIDI CC that goes from 0 to 127, you're dividing that by 127 to get a floating point value that ranges from 0 to 1.

    If you want the control surface to operate full duplex i.e you wiggle something in Sonar and the control surface updates (e.g motorised faders or encoder rings), then you will use MIDI out to send back a message to the control surface, and you poll all the things you're looking at regularly (Sonar calls you regularly to wake you up, but unfortunately doesn't tell you what's changed, you have to work that out). Most control surfaces accept the same message they send to set their surface values e.g a motorised fader that transmits MIDI CC 23 from 0 to 127 should also accept CC 23 and the value will position the fader. To avoid having faders 'fight' you you may need to determine whether the fader is being touched (if supported by the surface) so that you don't try and move the faders while the user is trying to move them.

    An easy way to get started therefore is to create an empty project and then hook into Sonar's callback (forgotten what it calls now, don't have the SDK in front of me) and set a single control to a fixed value, just to see something happen. Then go from there progressively. Also you can make hard-coded calls to e.g set channel 1 gain to 0.5 and verify you've got that licked. It took me a week or so working nights to get my head round it.

    #2
    maxberg
    Max Output Level: -90 dBFS
    • Total Posts : 17
    • Joined: 2008/12/06 17:40:46
    • Location: Austria, Vienna
    • Status: offline
    RE: Control Surface SDK 2008/12/17 13:38:43 (permalink)
    Hey aj!!

    1000*thanks for your answer and tipps!!!

    The problem is that I'm currently working on my own device and so I need the very basics of the SDK (at first^^)
    but I don't know how to start... I read your example of the BCR2000 and I have learned a lot!!
    But anyway I don't find the "Entry Point^^" You know what I mean =)
    What do I have to do if I would (for example) like to switch one track "solo" by pressing a key a note(I have my own device, it sends the midi)?? (I know the midi-protocoll.. that's not the problem)
    How do you start programming with this SDK???

    Have an nice evening!!!

    Max

    (Sorry for the bad English, I speak German =) )
    #3
    lost tears music
    Max Output Level: -89 dBFS
    • Total Posts : 72
    • Joined: 2008/05/03 06:46:03
    • Status: offline
    Re: RE: Control Surface SDK 2011/03/21 00:05:48 (permalink)
    HEy maxberg!! have u had any luck with the SDK?
    #4
    Jump to:
    © 2024 APG vNext Commercial Version 5.1