News:

CWP2Song, public beta.
My  DAW is Reaper
YouTube channel

Main Menu

BCR2000-preset, beta 3

Started by MarKo, July 05, 2015, 10:43:48 PM

Previous topic - Next topic

MarKo

Now i have another reproducable crash related with plugins.
i have some plugins on tracks 1-8.
Toggling ACT and the first plugin does reliable open/close - so all ok.
When i now move WAI to tracks 9-16 (where i have NO plugins) and try to toggle ACT (which should open first plug), Sonar crashes immediately.
Looks like PlugIns must be in the current "range" of WAI, or else crash.

azslow3

I hope you can provide some example for crash (the preset and exact sequence what you do, may be with project or at least description which tracks you have).

Unlike ACT MIDI AZ Ctrl has no "toggle ACT", so I am not sure what you mean. To open gui on the first FX plug-in on first WAI track, you should use something like:
* Strip/Track/<first in WAI>/add +0/Volume  - WAI Track Volume
* FX/<any>/skip 0/Parameter 1 - FX <any> shift 0 parameter 1
* Function/Context/Open - Open

Please note that Focus and Close (!) work exactly the same way. You need manually specify strip/FX. I just use what Sonar provides, may be I just have not found the trick, but I do not know the way to find currently focused plug-in.

For pro-channel the sequence is more complicates:
1) to ACT focus PC module, the strip should be focused. I mean Function/Select strip after WAI Track Volume
2) use Focus instead of Open.

Focus/Open/Close Next/Previous work different way. Again Sonar internal. Sonar knows where the focus is. They work for FX, Synth and PC (whatever is currently focused), but: for FX, all plug-ins are in the list, strip independent; for PC only modules for current strip are in the list, for Synth all Synth are in the list (but not FX).

In my MCU preset, I use Software Set for "current" plug-in. So, when I move to the next FX plug-in I explicitly increment the state, so I know what should I "Close". I do not know other way, sorry.

MarKo

#62
I could provide an crash-example in the evening, but it seems i was doing something wrong. And i did´nt want to blame AZ for the crash, i just wanted to know how plugin-handling works best. It seems you have it working good in your MCU, so i will try to understand what you are doing there.
I was not aware that i should use strip-select and FX before open.
Do you mean i should check after FX<any> if last action:success? can this avoid the crash if there is no FX?
QuoteAZ Ctrl has no "toggle ACT", so I am not sure what you mean
sorry for being unclear, i was talking about a button on BCR, which i just call "ACT"

azslow3

Quote from: MarKo on July 27, 2015, 09:50:25 AM
I could provide an crash-example in the evening, but it seems i was doing something wrong. And i did´nt want to blame AZ for the crash, i just wanted to know how plugin-handling works best.
From your description, the crash is at least initiated by my plug-in. I obviously try to avoid that, even when the problem is not really in my code and even when the preset is incorrect. I have thought that I have covered related crashes already, but it looks like I have overseen something.

Quote
It seems you have it working good in your MCU, so i will try to understand what you are doing there.
MCU is working with plug-ins directly, without ACT. So that is not a good example how you should proceed.

Quote
I was not aware that i should use strip-select and FX before open.
Reading my own documentation, I see that I have found the way to "Close" current ACT plug-in! I somehow forgot that when I was writing my previous replay. In rather bad English, but the information is here  ;)

Quote
Do you mean i should check after FX<any> if last action:success? can this avoid the crash if there is no FX?
No, that is done internally (till I have some bug here, which should be found and fixed on my side).


MarKo

So here is the crash example as it happens on my system (rename to zip).
The preset is quite minimum. Import the preset and attach 3 buttons for Mode and WAI left/right.
After opening the project, you have to change WAI right/left twice (don´t know why thats neccessary, but before no plugin would open).
Then: If WAI is on Trk1-8, you can open/close first PlugIN with "mode"-button.
But if you switch WAI to the right (9-16) and then try to change "mode" it crashes.
I´m sure it´s wrong what i´m doing there, but you wanted to know crashes which you did not cover.

azslow3

Thank you for the example! I could reproduce the crash and modify my source. I had no sufficient checks for "Open" and Sonar is crashing instead of simply failing to execute what it can not...

I attach modified preset with what I have found working for your "Mode" button. Please note that I am digging the same way as your, checking what is working and what is crashing. So I do not pretend that action combination is the best.

The idea:
1) We Focus current track volume. It is possible to focus any parameter (yes, focus is working for exact parameter, ACT context is just a "side effect" of focusing a parameter inside plug-in).
2) Then we try to select the first FX plug-in (really the first parameter in the first FX plug-in).
3) In case the plug-in is there, we can Open it.
4) In case the track has no FXes, we ask Sonar to Open Next plug-in. It looks like Sonar start scanning from the strip which has parameter  focus (from (1)) for any FX plug-ins (but not Synth and PC, till there is no FXes at all which I check since that crashes sonar). My first idea was avoid (3), but for some reason Sonar skip the very first FX in the focused track in "Open Next".

For close, I select the first ACT parameter and ask to Close whatever plug-in it is in (I check it is not ProChannel to avoid possible crashes).

MarKo

Thanks for the fix and the modified preset.
I hope to have time in the evening to check that.

MarKo

OK, this seems to work much better.
Although i still have to try what´s the best way of plugin-open/close (it doesn´t work all the time, depending on focused strip). But i did´nt have any crash since b277, that´s very good!

azslow3

Well, if it still does not work, I can make "Select FX" Function. It will search for FXes starting currently selected (I mean in plug-in) strip till the end of this strip type.

Bassman

Moin moin:)

Ich sehe ihr arbeitet hart:)  Stelle heute um auf Windows 10 und verbinde das mit einer komplette Neuinstallation, die letzte ist schon fast 2 Jahre her und es hat sich ziemlich viel Müll angesammelt, d.h. es funzen viele Sachen nicht mehr so richtig und der ganze Musikballast wird mir auch langsam unübersichtlich, Sonar 8.5, X1, X2, X3, alles noch drauf:(

Das muss alles weg!!!
Aber ich bin nicht weg, setze mir eine neue Partition auf, das Alte lass ich mal vorsichtshalber....

Haltet mich auf dem Laufenden;)

Danke und bis denne,
Heinz.

P.S. Macht sehr viel Spass mit eurem BCR Preset!!!!!

MarKo

Hi,
ich tüftel noch an einigen Verbesserungen, zb. Spuren fokussieren/markieren mit Solo lang drücken.
auch bei den PlugIns muss ich nochmal schauen, aber das tat zuletzt schon ganz vernünftig.
Den Fehler bei +/-dB hab ich auch noch gefunden, und der TRK<> hat jetzt eine 1:5 "Untersetzung" - reagiert also nicht mehr so übersensibel.
ich denke am Wochenende weiterzukommen...

azslow3

I have uploaded the version with "Find FX" function. So, the sequence to open first existing FX (if any) starting current strip is:
1) Select Track <current> Volume
2) Function Find FX
3) Function Open

You can check for "Selection Invalid" after to detect no FXes (and so may be not change to ACT mode in this case).

I have already asked myself how to find Synth corresponding to the focused track, and I do not have any solution yet. It can be: MIDI track with output to the synth, audio track with input from the synth or "Simple" (not detectable!) track which has absolutely no information about the synth (from CS perspective)...

MarKo

QuoteI have uploaded the version with "Find FX" function
Thank you, i will try that later.

Now i have another question: if i´m using a pure virtual control for loopback - how do i assign an unused midi-CC (without reprogramming my BCR)? i mean is it possible to manually "assign MIDI" - a specific unused CC, if my controller currently does not generate these CC?

MarKo

You can forget the last question (although it could be helpful), i found another solution.
I´m now using real buttons for my loopback-actions, but send a "magic" Value: 42  ;)
so i can detect if it was the loopback, because the real values are 0/127.
But i think it could be "cleaner" and less complicated to use a virtual control.

And another idea:
while trying different solutions, i had a scenario where i wanted to send a CC-number based on a state.
E.g. like CC: <State> Add: x
Same could be done for the CC-values.
Currently i don´t need it, but wouldn´t that be a nice addition?

azslow3

I will answer the second question first, because it is simpler.
You can use "SysEx/Midi" action (former SysEx) to compose arbitrary MIDI feedback. You just have to select "MIDI" instead of SysEx and compose valid simple MIDI (from constant HEX bytes, state position, HEX state names or even text).

About sending something to sonar.
My thought was to avoid external loopback, and I was so close to the solution when I have found it does not work perfect... Sonar support VST MIDI output and can route that to tracks. So by special automation parameters it is possible to "inject" arbitrary MIDI to Sonar. Unfortunately, that routing is done with one full round trip time delay. So, that is not going to work well for live sending.
To use external loop driver, use "Master" mode for the real preset (default is "standalone") and insert additional AZCtrl instance(s) connected to the loop device.  The only configuration for them is "Slave 1,2,3". You can send MIDI to these instances (using Device parameter in MIDI/Sysex actions), which can be looped back into sonar. I have not measure the latency of that, so either it is going to work better then VST solution is a good question.
Next method to try in my list is MFX plug-in with injection. It looks like MFX is processed in the same round trip cycle, so it can be the best solution from latency point of view. Unfortunately, there is no way to directly record MFX output. So, while reasonable for live use, the result is not "recordable".