Recent Posts

Pages: 1 2 [3] 4 5 ... 10
21
Discussions / AZ Controller Not Seeing Sustain Pedal?
« Last post by jmwolfe on January 16, 2023, 10:18:17 PM »
Hi! I am fairly new to AZ Controller, but have managed to set up all the basics. Now, I would like to use my foot controller in DAW mode to trigger some commands. However, "Last MIDI Event" does not seem to capture my sustain pedal activity, though I can see Cakewalk sees the events. I think maybe the "DAW" mode on the keyboard doesn't send footpedal events. Some other way around this?
22
Discussions / Re: Alternative method of track to group routing
« Last post by norfolkmastering on January 09, 2023, 04:09:17 PM »
Hi Alexey

Thanks so much for updating the test preset and for the explanations.
I'll spend some time experimenting with this approach and let you know how it works for me.

Best regards
Robert
23
Discussions / Re: Alternative method of track to group routing
« Last post by azslow3 on January 09, 2023, 02:40:04 PM »
Hi Robert,

I attach proposed approach. Note that "Timer Once" should have priority 0, so higher then any SysEx sending Monitor. It will work also with other priority,
but can introduce more then one cycle delay (depends in which order monitors are checked).

You may ask why I explicitly reset Timer Monitor, instead of just defining State Monitor which should be triggered automatically.
The answer is... it seems like State Monitor has a bug under such use ;)

So, before sending any SysEx I forbid triggering any other SysEx sending Monitor and schedule resetting of that block for the next cycle.

Text = "" is a correction for original example. If there is no specific Bus/Track, Text = "Parameter name" has no effect, effectively the last value of Text
will be preserved. That can produce "side effects" in complex presets (sending SysEx with wrong name for not existing output/bus).

"Display" actions are just for me, to test how all that works (since I don't have PIC to receive SysExes). Initially I put "~1sec" in Reset options to test, and Display
was updating one by one. With "at next" it should update with cycle delay.

Cheers,
Alexey.
24
Discussions / Re: Alternative method of track to group routing
« Last post by norfolkmastering on January 05, 2023, 10:49:07 AM »
Hi Alexey
Thanks for offering to modify the preset to demonstrate blocking.  This looks a promising solution to the issue.
Regards
Robert
25
Discussions / Re: Alternative method of track to group routing
« Last post by azslow3 on January 04, 2023, 10:24:57 PM »
Hi Robert,

You can initiate request-reply for names from PIC, by sending some MIDI from PIC and directly sending the name as the reaction, so without monitors. But then changes  in names are not going to be send.

Cycles are loops, when specified  reset after "X seconds", that means X*13 cycles (since default cycle is 75ms...).

I can modify the example... probably not before weekend... to demonstrate blocking. If any monitor send SysEx, it set "SysEx_Sent" Set to "Yes" and reset special "Timer once" Monitor at "next" cycle. That monitor with 0 priority reset "SysEx_Sent" to "No". All sending monitors should have "SyeEx_Sent:Yes - Undefined final" before the monitor in the logic list.
So, if any Monitor is triggered SysEx_Sent is set, so all other monitors will not be triggered in the same cycle. High priority monitor will unset the State at the beginning of the next cycle, so some other Monitor can send SysEx.
That should work fine at the beginning/project changing and for "run time" renaming.
26
Discussions / Re: Alternative method of track to group routing
« Last post by norfolkmastering on January 04, 2023, 06:24:32 PM »
Hi Alexey

Further to my last message.

I just discovered that it is possible to do selective action monitor resets.  I did not realise that this was possible and it is a potential solution to my issue.

So my idea is that the PIC can send a MIDI command to trigger only some/all of the output name SysEx messages.

However this depends on a Monitor reset feature I don't fully understand.  So can I ask:

For a single each action Monitor reset, there is an option to change the trigger timing .e.g. 'after 2 cycles'.  Can you tell me what each cycle means?  Is this multiples of the Cakewalk refresh rate or another timing measure?

Sorry another question.  Could you increase the number of trigger timing options?  The cycle limit at the moment is 11 cycles.  Could you extend this drop down?  say to range up to 127 cycles?

If this is possible, then I could put all of my routing SysEx actions into a single Monitor reset but with each action having a different trigger delay.  Would that space out the SysEx messages from AZ as I require?

Best regards
Robert

27
Discussions / Re: Alternative method of track to group routing
« Last post by norfolkmastering on January 04, 2023, 11:49:22 AM »
Hi Alexey
Thanks for your advice.

I tried setting the speed to "Normal" for the relevant monitors but it did not fix the issue.

My cycle time is set to 25ms, so if there is a way to configure monitor blocking then this may provide a practical solution.

Using my test preset, is it possible to set monitor blocking so that;
If 'Track1' is checked in one cycle, then 'Track2' and 'Track3' are not checked in the same cycle?
Then 'Track2' is checked in the next cycle but 'Track3' is not checked in that cycle.

So what I am trying to achieve (using the test preset) is that only one 'Trackx' is checked per cycle.
Is that possible?

Regards
Robert
28
Discussions / Re: Alternative method of track to group routing
« Last post by azslow3 on January 04, 2023, 09:44:45 AM »
Hi Robert,

AZ Controller does not support that. You can try to set speed to "Normal" for corresponding monitors, if I remember correctly that should "spread" monitoring a bit. Alternatively explicit monitoring blocking can be organized (so after 1-n sends other monitors are not checked in the same cycle). But all that will be timed in cycles, so 75ms (default) or whatever you currently use.

I was thinking about a separate thread for quantized MIDI sending several times, but so far I have managed to use other approaches. Cakewalk is obviously "ready" for MIDI sends during MIDI processing and timed cycles (it initiate both), but I am not sure what happens if I start sending at random times from different thread. You know, when something was never foreseen, that is probably buggy.

Cheers,
Alexey.


29
Discussions / Re: Alternative method of track to group routing
« Last post by norfolkmastering on January 03, 2023, 10:26:34 PM »
Hi Alexey

I have the routing system based on labels working.
There is one issue.
As the PIC has to do a lot of data processing for each received label, I think I am losing some routing MIDI messages from AZ to the PIC when the bulk dump is carried out.  This is part of the start-up process when a Cakewalk project is opened.

Is there any way to affect a small delay between each of the SySEx messages, so I mean perhaps 10ms?

Regards
Robert
30
Discussions / Re: Alternative method of track to group routing
« Last post by norfolkmastering on December 30, 2022, 12:31:56 PM »
Hi Alexey

The modified preset works, thank you.

When I load a Cakewalk project I get a dump of all the bus names and output names.
When I change a name, then I get a feedback message.
So I think that is enough information to modify my PIC programme.

Your suggested use of SysEx prefixes unique to each track or bus will allow me to identify exactly which label I am receiving.

I need to work out the best way of storing and comparing the received SysEx messages.
I think my options are to either:

Convert the received values back to character strings and then use the C function strcmp to match track output names to bus names (so I do the correct audio routing in my mixer).
OR
Store the received values in numerical arrays and then try to find a high level C function to compare numerical arrays. (I have not been able to find a high level function yet).

Thanks again for your help with this.  Not only will this improvement allow me to change bus names as a recording and mixing session evolves, it also opens up the possibility of rearranging the Cakewalk displayed order of busses which is not possible with my current PIC software.

I'll let you know how the work progresses.

Regards
Robert
Pages: 1 2 [3] 4 5 ... 10