News:

CWP2Song, public beta.
My  DAW is Reaper
YouTube channel

Main Menu

Capture event's

Started by Pan65, March 08, 2017, 12:48:37 PM

Previous topic - Next topic

Pan65

Hello

I wonder if there are a way to capture event's from  Sonar and perform certain operations based on them. I'm thinking of events like Project Load, Project Close, transport Play and so on. It would be really nice to set state's based when something in Sonar is changed.

azslow3

AZ Controller will be unable to do 90% of what it can without such facility!

That is called "Monitoring", it is described in the Manual and "Buttons or pads with LEDs" tutorial. The topic is a bit tricky. It could be implemented the same way as device control changes, f.e. a virtual button "Play". But that i not sufficient for complicated logic, event for "Play" you also want "Not play" (not the same s Stop, can be Record). So the concept is to define "what will be done in case something happens" following by reacting on that "future" change. That approach can animate LEDs, show information on display / OSC controler, send some MIDI, etc.

Mentioned by you examples fall into "State Monitoring" category. For Project Loaded monitor "Context", for transport "Transport" System State Sets. But that is just a small part of things which can be monitored and the type of monitoring (f.e. for some track/VST parameter you can monitor name, value, read or write automation for that parameter, for strip volumes also levels; it is possible also monitor existence, for example do something as soon as current strip has particular plug-in; and more...).

Pan65

Thanks for the quick reply.
Yes I've seen the monitor command but I'm not sure how to read from it without first having to trigger an event from my controller. I don't  understand how I set things up to listen for events coming from Sonar.  The tutorial you mentioned is quite complex and it is not easy for me to follow the logic of it.

It would be nice with a simple steps by step tutorial that do something when sonar is playing and something else when it has been stopped.

I'm right in the begging of learning the logic of your magnificent interface. Right now I have setup my controller to deal with basic strip actions like level, mute, solo and so on. But I am planning to make it more complex so I can controll plugins and also to get feedback to lcd-display and led's. I have a Novation SL MKII by the way.

azslow3

Novation (and other) is charging for the software (may be more then for the hardware) for a good reason. It is not easy to organize be-directional cooperations, even in platforms like AZ Controller.

The very first question to answer, do you know that you can control your controller LEDs and Display with MIDI? I mean from what I know, most Automap products had no "external" midi protocol for the feedback.

If you have the documentation, to create reasonable preset, please follow (in the sequence):
1) I guess "Quick start" you have done
2) "ACT MIDI Explained" tutorial. It is long but it is step by step. It does not explain the feedback, but all other aspects are covered (most imported how to use "Software States", you will need that for the feedback)
3) "Using AZ Controller Internal Display" is a simple step by step Monitor tutorial. Not for transport, but that can be an exercise for you to modify it to display current Transport state on the (internal) display. At that point, you can already try to display something on Novation as well.
4) read the whole manual. I mean just read, may be many parts will make no sense for you, but you get the picture what is there in general
5) return to the "buttons and LEDs" tutorial.
Till you understand what is going on in (5) you will be unable to organize correct feedback. Sorry.

Play LED by itself is easy. In the "Logic" you define "Monitor / State Monitor / Transport" action (can be in the same control as you use to react on the play button, so near "Command / Play/pause" Action). In the "Feedback" Tab, for that monitor, you send MIDI  LED On with condition "Transport:Play" and marking "Is final". Then without conditions MIDI LED Off.
Whenever transport state changes (also on preset loading), that feedback section will be called. So you updated the status of the LED.

But I will have to retype the whole manual and tutorials to cover all possible cases, there are 100s (may be even 1000s) of them! There are different cases when you want LEDs to light, in different "modes", under different conditions. Also preparing required MIDI signal can be not so easy, even when the format is known.

Pan65

Thanks again  :)

I think I get it now... I can actually create a "DUMMY" control in the options tab and specify some monitor action there, then I go to the feedback tab and edit desired behavior there, Right? The whenever a change occur the code I specified in the feedback tab will run? I have to try that and see what happens...

About the SL MKII documentation, I've been in contact with the support and waiting for a reply. Until then I keep my fingers crossed, but I've seen similar documentation for other Novation products on the web so there is hope I guess.

Maybe I should tell a little about my background... Beside being a musician (as you may have guessed) I've been developing since the mid 80's, not professional though. Visual Basic is my main language but I've done some C++ and Java to, not to mention a couple of scripting languages such as Perl, Rex among others. I was actually planning on making my own interface when I came across this site and thought (why invent the wheel again?).

With that said I think I will get my head around the logic of your interface eventually, but it's a lot to take in at the moment. The documentation is good but in some parts I feel there could be a little more details, and maybe a few examples here and there would help to. But I know it is a daunting task to write manuals and I really hate that part myself, it's easy to forget all the features in a huge project like this one.

Hope you don't mind me bugging you with more questions and suggestion in the future, I'm sure there be quite a few :)

azslow3

Quote from: Pan65 on March 08, 2017, 07:34:51 PM
Thanks again  :)

I think I get it now... I can actually create a "DUMMY" control in the options tab and specify some monitor action there, then I go to the feedback tab and edit desired behavior there, Right? The whenever a change occur the code I specified in the feedback tab will run? I have to try that and see what happens...
Yes, you can create controls just for monitors, or as "functions" (to call from other controls). For State Monitors (like Transport), there is effectively no difference where it is defined. For value monitors, that is important since the part before "Monitor" Action really defines what is going to be monitored.

Quote
About the SL MKII documentation, I've been in contact with the support and waiting for a reply. Until then I keep my fingers crossed, but I've seen similar documentation for other Novation products on the web so there is hope I guess.
Novation newer devices are real MIDI controllers. Some have complete documentation. Novation old devices are Automap only (f.e. I have Nocturn). They can be MIDI devices throw AutoMap application, with "User" mode or "HUI" mode. In the later it should be possible to send complete feedback using HUI protocol.

Quote
Maybe I should tell a little about my background... Beside being a musician (as you may have guessed) I've been developing since the mid 80's, not professional though. Visual Basic is my main language but I've done some C++ and Java to, not to mention a couple of scripting languages such as Perl, Rex among others. I was actually planning on making my own interface when I came across this site and thought (why invent the wheel again?).
Than you probably can understand another explanation for Monitors: Sonar API is not event driven, it is not possible to define a "hook" to let say transport state. But it is possible to ask which state it has now. And Sonar calls the plug-in ~13 times per second (precisely 75ms interval, configurable in Sonar options). So to imitates event driven logic, AZ Controller check the transport state 13 times per second, but it calls relevant code only in case it is changed. Other monitors function with the same logic (but they have "speed" parameter to check for changes slower then 13 times per second, while was introduced in the beginning, I never use slower speeds... compare to any VST, AZ Controller does not produce significant load on modern processor even with full speed 2000 monitors defined, which an "interpretor" style, AZ Controller scripting language is effective ).

Quote
With that said I think I will get my head around the logic of your interface eventually, but it's a lot to take in at the moment. The documentation is good but in some parts I feel there could be a little more details, and maybe a few examples here and there would help to. But I know it is a daunting task to write manuals and I really hate that part myself, it's easy to forget all the features in a huge project like this one.
All features are documented. I update the Manual as soon as some code is added, at least to remember myself what is there. But many features can take a whole chapter to explain, that I do not do. When I have time, I create tutorials.

Quote
Hope you don't mind me bugging you with more questions and suggestion in the future, I'm sure there be quite a few :)
You are welcome. Please do not hesitate to ask any questions.