Future plans

[azslow3]

I think it is good idea to make the list of pending task into public...

Feel free to comment.

• Proceed with Yamaha 01Y configuration
• V-Studio 20 preset & Co
• StudioMix preset. Required components are already there (Faders/Encoders "fixes", MIDI processing). Tests are promising (especially I like jogging with zooming and setting loop points, but faders are also handy). My device has too many hardware problems... Till that is fixed, there is no reason to continue with the preset.
• Plug-in management. I have found that many features I want require quite some knowledge about each parameter of each plug-in (VST). Most probably "hardcoded" originally, the mapping with parameters should find its way to the UI then. I want introduce some "Categories", to define "EQ"/"Compressor"/.... (whatever) with a set of parameter available to choose in the preset and a possibility to map (yes, yet another time...) particular plug-in parameters to that categories. That way in "EQ" mode any plug-in can be used without special coding for them. I can not just use ACT for 2 reasons: ACT is only mapped for one plug-in in time and ACT has no information about real parameter type (continuous/discrete/switch) and the "default" value. Really long coding is required for that.
• A&H Qu control. I mean the possibility to control Qu by Sonar, not Sonar by Qu (which is already possible). One significant modification is required in my MIDI processing engine.I have implemented all required changes, but it will be nightmare to test without the device.
• Curves to match physical scale near sliders to the logical scale in Sonar. Not sure which way is better for that yet.
• Text forms for actions lists
• Reword Mack. preset, display part. Add values for ACT

[MarKo]

Hi Alexey,

i was very busy the last days, but i´d like to take the opportunity to repeat a wish.
if we had a way of exporting/importing the actions-lists in some text format, this would be very helpful. i would prefer text, because it´s editable and we could use all kinds of search/replace or even regex.
In my current preset, nearly every line in the action list has some dependency on a numbered state (pic), and i have to copy/paste similar lists for 32 controllers.
So it´s very cumbersome to copy/paste and then check/edit every single line, and that additionally for the monitors. I have not counted the clicks, but that´s really not funny.
And i think i had at least one mistake in every copied list, because there are so many places to change. With a good editor, this could be done with search/replace-makros once for all controls and without mistakes.

[azslow3]

Ok, added to the plans...

But please do not expect any diagnostic when there is a single mistake in the text. I have no plans to create full scale compilator with advanced diagnostic.

In reality, I create "build in" presets as a C code. So I have all regex/copy/paste/etc. tools when I am working with that. Believe me or not, it is slower an more error prone then preparing a "template" in one control, copy the list (all at once, not one by one) into other controls and adjust conditions/states/actions after. I normally test every single control in any case sine the error rates coming from the program form as well as from in-plugin modifications is far from small in my case. When I modify in plug-in, I can test immediately (just be using corresponding control). With program/text form there is an additional operations to load the preset and restore required operation mode.

I was already thinking about text form. Not as an editable representation for complete preset but for simple idea sharing in the forum. But nothing will prevent copy some blocks to text file, modify it there and paste back to the plug-in.

[MarKo]

Ok, added to the plans...

Thank you!

But please do not expect any diagnostic when there is a single mistake in the text. I have no plans to create full scale compilator with advanced diagnostic.

i can fully understand you, but i think anybody editing such files is aware that he does "unsupported" stuff.

Believe me or not, it is slower an more error prone then preparing a "template" in one control, copy the list (all at once, not one by one) into other controls and adjust conditions/states/actions after.

well, that´s how i do it now, but as i said, this is very error prone for me

What i really want to achieve, is on pasting a complete list with "variables" that every "variable" gets incremented. So that "Strip:First in Wai" becomes First in Wai+1, Send1 becomes Send2 and so on. That would be quite simple, but then also the involved States (eg. S1_Mode) have to be incremented, and thats a problem because there´s no way of knowing which of the States should be incremented, and which not (also, they have to be created first). And then also in monitors the controller-numbers need changes, so this is really much work.

I was already thinking about text form. Not as an editable representation for complete preset but for simple idea sharing in the forum. But nothing will prevent copy some blocks to text file, modify it there and paste back to the plug-in.

i think it would be very helpful (even if it´s too late for me, because i´m slowly approaching a completely redesigned BCR-preset).
Also when checking a small function in a separate preset (which i do often) and afterwards pasting into the full preset, or when exchanging functions with others, or to/from other presets it´s useful.

[azslow3]

What i really want to achieve, is on pasting a complete list with "variables" that every "variable" gets incremented. So that "Strip:First in Wai" becomes First in Wai+1, Send1 becomes Send2 and so on. That would be quite simple, but then also the involved States (eg. S1_Mode) have to be incremented, and thats a problem because there´s no way of knowing which of the States should be incremented, and which not (also, they have to be created first). And then also in monitors the controller-numbers need changes, so this is really much work.

I wish some good idea visit me some day, I am thinking about that for long time... 

In monitors I have, controller numbers are usually the same as in the corresponding control. In such lucky case, it is not required to set it explicitly.

Every time I do some big modification, it does not take more then 5-20 minutes to complete. At the end, that is not every day/project operation.

[MarKo]

I wish some good idea visit me some day, I am thinking about that for long time... 

Just a "pragmatic" idea:
- additional button "paste with increment"
- all values like strip:add+x, or send:number x, get incremented
- in all states/conditions names, the first number is incremented, so S1_Mode gets S2_Mode, but S1_R2 gets S2_R2
- explicit controller nr´s also get incremented
i hope you understand what i mean, but i think this could be working.

Every time I do some big modification, it does not take more then 5-20 minutes to complete.

uff - i need that time for just a handful of controls, but i have 32!

At the end, that is not every day/project operation.

not when working with AzCtrl, but when working on the presets!

[azslow3]

I wish some good idea visit me some day, I am thinking about that for long time... 

Just a "pragmatic" idea:
- additional button "paste with increment"
...

And add functions for each possible actions which check all possible parameters for desired effect
I will revise all actions for text import/export, let see what comes out. I just worry that in case of dual mode like in ACT MIDI, when in one mode you control all parameters of one strip and in another you control the same parameter from different strips it can be hard to decide what to increment.

Every time I do some big modification, it does not take more then 5-20 minutes to complete.

uff - i need that time for just a handful of controls, but i have 32!

I do not normally rewrite everything at once. But I had feeling I want revise Alphatrack (2.5k lines). That took several hours (but it is 1.5k now and one half of the file size, while it generates the same result).

[MarKo]

And add functions for each possible actions which check all possible parameters for desired effect

ok, then the famous DWIW-button would be even better

I just worry that in case of dual mode...

after thinking again, i believe you are right.

That took several hours (but it is 1.5k now and one half of the file size, while it generates the same result).

surely you are x times faster than me, but another point for me is that did not have a fix plan (i hope to have now) because i did´nt know about all possibilities. And by slowly learning the different ways to "code" these things (and implementing more and more) i had to change my plan and rewrite quite a lot. And as the action-lists get longer, it gets more and more cumbersome, esp. because i have to do this copy/paste/edit stuff for 32 controls.

I will revise all actions for text import/export, let see what comes out.

that could be very helpful.

[azslow3]

I decide to let you know why there is no updates... I want implement "curves" editing. And for that I need some nice graphical widget... And that will take some time 

[azslow3]

Just to let you know what is going on, since there was no big updates recently...

I was looking at OCS and thinking how to proceed. Before there was Web based test (as you could find, there is web transport control as separate plug-in), but OCS looks more promising in respect to stability and the user interface. I will test myself with TouchOCS (on Android) and SurfaceEditor (on Linux), but the result should be able to cooperate with other OSC capable apps.

Why OSC? Available on all platforms user build OSC surfaces looks like the perfect choice to organize all range of complement to Sonar controls. That can be a "display" for hardware controllers (to show strip and parameter names, markers, etc.), stand alone touch surface, an imitator for hardware (for me to simplify controllers support, for you to test what you will be able to do with some controller prior the decision to get it).

Why not MIDI? While most OSC apps have OSC2MIDI translators, for CS purpose has several limitations:
a) not so easy to setup. You need CS configuration for MIDI -> Sonar MIDI configuration -> OCS to MIDI daemon -> App. With direct OSC support, 2 intermediate levels are not required
b) MIDI is tricky when it comes to more then 7bit values, everything above 16 channels requires at least 2 messages per value (more general 4)
c) MIDI has no standard to transfer the text. And that is what I (and probably you) want to see on your devices. That was the deal breaker for me to search for other solutions.

Please do not expect something soon, it will come when it come. But I at least think about it and for most theoretical questions I already have practical answers in my head.

[azslow3]

OSC took a bit less then I was expecting 

I think its time to deal with plug-ins. I have already reworked posts about ACT. Probably the first part will be "ACT Fixer", I have the feeling that "not working ACT Learn" can be solved in place (except for VST3). As next some kind or "Plug-in editor" should come, in direction of ACTEditor from MarKo, but probably quite different. I want at least parameter type (continuous or multi state switch) and default value.

[azslow3]

After fiasco with StudioMix (I have not managed to make the hardware sufficiently reliable, not even encoders...), I decide to give another Cakewalk labeled hardware a try. That time it is (Roland) V-Studio 20. At least it is in good conditions and everything (on hardware part) is working.

The first experience is mixes:
+ driver installation was smooth, apart from usual acrobatic  with Win8 driver under Win10
- ASIO produce pops and clicks with any settings and buffer sizes I have tried. On any Sonar operation (record, mute, stop, even looping (!)). In normal linear recording and playing everything is fine, starting from 12ms latency (works under 10, but not stable, probably will use that to test software guitar sims). I hope I will find the reason, and I hope it is not going to be Win10 incompatibility...
+ WDM/KS do not show the same symptoms. But on lowest setting (18ms) and attempt to record kill the Audio Engine. With 35ms everything green. Note that my M-Audio, with 10.5ms in "relaxed" settings never had any such problems.
+ Control Surface works
- Control Surface is only transport, volume in "jump" mode and combined select/record arm. So, there will be AZ Controller preset. Also I have thought to add a kind of "StudioWare" since I have found a bit funny that apart from preset changes, controls can not be used to operate effects.
- No silence detection, rather bad decision for guitar oriented device with build-in mic.

A comparison with LivePlay GTX
* LivePlay has definitively more features. Not only way more connectors, stand alone, display and huge set of effects, but also class complaint and so no problem with drivers.
* but V-Studio has own advantages: 24bit and I think better recording from all sources, has normal line inputs (which can be recorded), for my taste amps are nicer, bus powered, DAW controls.

And so for use with a notebook and for recording V-Studio is not bad. And for current e-bay price it is ok. But original introduction price was way too hi for such device. No wonder it was abandoned rather quick.

[azslow3]

I have not published plans for a while.

At the moment all my time is invested in accessibility tools. Two major projects are ongoing:
1) Screen Reader which can read the screen... Normal screen readers can not, they just read the information behind the screen. Most current music software is not providing this information.
2) Accessible OSC controller for windows.

[dirtyharry]

I am a newbie here, and have to say I'm very impressed with the capabilities of AZ Controller ( I hope you have shared your source code with some trusted people so it is never lost ).

I have a fully working StudioMix (apart from a little encoder jitter), and simply love it's form factor and potential ( let down by the supplied plug-in ). I was originally looking at either writing a translator of it's midi messages to Mackie protocol, or even modifying the Mackie control surface sample. I had read through the AZC PDF manual and was initially discouraged about bi-directional control. However I finally figured out the AlphaTrack preset is built in and was blown away by the level of bi-directional control. Great work, but I'd still like to try and get the most out of my StudioMix.

I have achieved very simple bi-directional control of StudioMix in AZC, but if I move the hardware slider it resists me, and if I move the Cakewalk slider the hardware slider jitters a lot before settling. I looked to your AlphaTrack preset for inspiration, but really couldn't figure out what _Fader and _CFader were intended for, but which I'm guessing are vital to separate the filtering or delay of messages in either direction, such that there isn't a motor/software feedback loop.

I finally landed here and found that you have parked a mostly(?) working StudioMix preset, but it doesn't appear to be published anywhere. It would be really appreciated if that could be shared ( with obvious warnings ), and maybe myself or others would be able to benefit and maybe return it back to the forum with improvements.


As you yourself have pointed out AZC and it's documentation is rather cryptic. Might it be possible for a future version to include an optional edit "notes" string against named Controls and States, and Action Lists per Logical Control. That would allow preset developers the option to annotate the workings of the preset. Just a thought.

Many thanks,

Richard.

[azslow3]

Hello Richard,

I will try to find my attempt for StudioMix (I don't see it in my collection and I have changed primary computer since I was working with it...).

Some workarounds are required for faders on this device. For other devices simple feedback approaches are working fine, but not for this one.
Since it has no touch sensitive faders (unlike Alphatrack, MCU, etc.), it doesn't know when you move faders by hands and when they should be moved by Cakewalk.
Other devices with similar hardware (f.e. BCF) are emulating MCU, so they have implemented related logic in hardware. StudioMix native plug-in does that on the
software side. You will need to do the same. From what I remember:
preset should "remember" initial movement and for a while assume that is the only direction. If feedback value is sent, it should assume any movements StudioMix reports
are the result form that feedback, so do NOT use them to modify Cakewalk parameter. Reversed, if movement is reported by StudioMix and there was no prior feedback sent, the feedback
should not be sent for a while.
That is possible to do in AZ Controller. But that is the reason why "MIDI translation into Mackie" will not work in practice.

For the reasons I have described in my original post, it is unlikely I ever put my StudioMix on my desk. At least not till I replace all internal parts. I like its "old bulk design", so touch sensitive faders, more LEDs, may be display... and it can be nice device