zyn-fusion continuously sends /active_keys messages

[zynmuse]

I have a client connected to zynaddsubfx using osc ( fundamental's RtOsc library). I can send and receive messages and change parameters etc.. - that is brilliant. As part of debugging my client, I changed my code to print out all the receive osc messages. I noticed that the zyn-fusion is continuously sending /active_keys messages followed by FFs about every 45 msecs.

RECV::/active_keys,FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF

any parameter change messages are also sent correctly between the /active_keys messages.

I recompiled zyn_fusion to use the older fltk interface. Now I no longer receive the /active_keys messages and all works well.

I think the repeating /active_keys messages may be a bug but only when the code is compiled with the new interface.

I would appreciate any help with resolving this.

[fundamental]

Odd as it may sound, that's intended. Basically both the fltk and the zyn-fusion GUI have some widgets which poll the backend to get updates over time. Certainly it's not the most efficient design, and I'd wager it would likely be good to shift the active_keys polling to once per 250ms, but it is what it is. With the old fltk based interface you should be able to notice polling for the VU meter. In most places where I have debug statements watching the OSC event stream within zyn there's an associated condition to filter out printing of those events.

As long as you're sending events to the backend 'zynaddsubfx' then you shouldn't see any of these events since they're sent as a query from one client and the result of the query is responded to only that particular OSC client. In cases where state is changed rather than just checked, there's also messages broadcast out to all listening clients, but that shouldn't be the case with /active_keys. (If it is, then that would be a bug in the zyn backend).

[zynmuse]

Thank you Mark for your quick response. I have also noticed the vu meter message.

I hope my questioning is not too basic, but I am trying to understand the interface. I've read as much documentation as I can find but my inability to understand is my problem. Responses to questions like this can clarify and save lots of time!

I don't know how to distinguish which messages which are broadcast. My code was based on oscprompt. I start zynaddsubfx with -P 1234 and my client connects to port 1234 using code borrowed from oscprompt. I assume that the messages I am receiving are from zynaddsubfx "backend " and not from the zest or fltk UI. I'm using messages received as a result of controls being moved on one or other of the UI's. Actually those messages could be coming from the UI or from the backend, I would appreciate any clarification you can give.

[fundamental]

On 10-26, zynmuse wrote:

I don't know how to distinguish which messages which are broadcast.

Welp, here's a not so fast response. I forget if I explained this elsewhere (I swear it's documented, but I don't recall where at this point).

The core idea is to mirror the style of REST for OSC urls.

You have /path/to/action+arguments, /path/to/param, and /path/to/param+value.

For self contained actions and reading parameters the only client who cares about the result is the client. When parameters chance value or when actions invalidate sections of the parameter tree (think paths like filesystem trees), then all clients care about the change in theory (you could refine it to clients interested in that subtree, but then you'd need to track that info somehow).

So read-operations, no-op parameter changes, and actions not effecting overall state will produce replies going to the client who sent the message. Parameter changes and large scale modifications trigger a message broadcast out to all active clients.

I assume that the messages I am receiving are from zynaddsubfx "backend " and not from the zest or fltk UI.

Correct. I think the zest of fltk UI print out what their OSC port is at startup. For fancy debugging you can attach instead to the GUI, but generally that's only happening when you intend to. Great for mocking the whole backend if you want to.

I'm using messages received as a result of controls being moved on one or other of the UI's. Actually those messages could be coming from the UI or from the backend, I would appreciate any clarification you can give.

So, what you should be seeing is:

Start zyn backend 'Z' Start GUI/client 'A' Start GUI/client 'B'

A talks to Z, Z remembers that A is an active client B talks to Z, Z remembers that B is an active client

A has a knob 'X' change to value '2'. A sends message over to Z saying X=2. Z updates the realtime parameter, noting that X was previously 1 and is now 2. Since the state change altered the parameter all active clients need to be alerted that the change has occurred.

Broadcast X=2 to active clients A and B. your client B sees the message.

[zynmuse]

On my previous reply, /Amp references should be replaced by /Out

On 01/12/2020 01:07, Mark McCurry wrote:

On 10-26, zynmuse wrote:

I don't know how to distinguish which messages which are broadcast.

Welp, here's a not so fast response. I forget if I explained this elsewhere (I swear it's documented, but I don't recall where at this point).

The core idea is to mirror the style of REST for OSC urls.

You have /path/to/action+arguments, /path/to/param, and /path/to/param+value.

For self contained actions and reading parameters the only client who cares about the result is the client. When parameters chance value or when actions invalidate sections of the parameter tree (think paths like filesystem trees), then all clients care about the change in theory (you could refine it to clients interested in that subtree, but then you'd need to track that info somehow).

So read-operations, no-op parameter changes, and actions not effecting overall state will produce replies going to the client who sent the message. Parameter changes and large scale modifications trigger a message broadcast out to all active clients.

I assume that the messages I am receiving are from zynaddsubfx "backend " and not from the zest or fltk UI.

Correct. I think the zest of fltk UI print out what their OSC port is at startup. For fancy debugging you can attach instead to the GUI, but generally that's only happening when you intend to. Great for mocking the whole backend if you want to.

I'm using messages received as a result of controls being moved on one or other of the UI's. Actually those messages could be coming from the UI or from the backend, I would appreciate any clarification you can give.

So, what you should be seeing is:

Start zyn backend 'Z' Start GUI/client 'A' Start GUI/client 'B'

A talks to Z, Z remembers that A is an active client B talks to Z, Z remembers that B is an active client

A has a knob 'X' change to value '2'. A sends message over to Z saying X=2. Z updates the realtime parameter, noting that X was previously 1 and is now 2. Since the state change altered the parameter all active clients need to be alerted that the change has occurred.

Broadcast X=2 to active clients A and B. your client B sees the message.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/zynaddsubfx/zyn-fusion-issues/issues/250#issuecomment-736150211, or unsubscribe https://github.com/notifications/unsubscribe-auth/APGUENTWVSTCXY73UWCFIJLSSQ6T7ANCNFSM4S6QVFMQ.

[fundamental]

On my previous reply, /Amp references should be replaced by /Out

Did github drop a message? I'm not seeing another reply with the needed substitution.

[zynmuse]

Thank you Mark

Here is the previous message again (with minor edits!)

The clarification is useful!

I'm seeing certain other messages which arise when Zyn is running (ie making sounds). One in particular I think I get a message with a path something like "/Out".

My system, waiting for the user to move a control on your zest interface in order to grab it's path and assign it within my system, sometimes will receive the /Out message and decide to use it rather than the intended control. Sending messages to /Out doesn't seem to do any harm!

I'm wondering if there is an easy way to filter out such messages - I like to be able to configure additional controls while zyn is playing. Maybe I can use the fact that the /Out message has two parameters /Out ii where everything else I use has just one (I think).

I watched your interview with Unfa and I think you talked about outputting the envelope from zyn and maybe that is what I am seeing!

All in all I'm very impressed with the way the osc interface, zyn and zest are working.

Initially it was intended to provide an automation level between LMMS and ZYN, but I got so in to the programming that I've now added a piano roll so it can work with zyn as a stand alone instrument. Couldn't see any reason to program a synth as zyn is brilliant! so I just decided to build something on top of it.

Keep up the good work!

Kind Regards John (Zynmuse)

[fundamental]

I think you talked about outputting the envelope from zyn and maybe that is what I am seeing!

Yep, that sounds right. The watchpoint systems should generally have /base/path/out (data). I think for instance if you were looking at a single LFO/envelope it would be .../out time, level

It took me a bit to realize how your client was seeing this event as it should be directed back at the client which requested it, but the sequence of events are:

zynaddsubfx worker thread:

• CLIENT 1 activate watchpoint
• CLIENT 2 any message

which is sent to the realtime side as:

• CLIENT IS CURRENTLY CLIENT 1
• Activate watchpoint
• CLIENT IS CURRENTLY CLIENT 2
• any message
• After messages are handled audio is processed
• Watchpoint gathers all the data it needs in the audio processing
• The watch point returns a message (unaware that the active receiving client changed)

Watchpoints should be the only thing working like that, though. All other messages should get back to the right client AFAIK. In terms of filtering messages, the high frequency traffic is the VU meter, status of the keyboard keys, and watchpoints. Everything else is generally sparse (though you will see waves of requests get fired out when a GUI client switches to a new view). There's a number of ways of filtering things based upon your goals. In particular it's possible for remote clients to fetch metadata about ports similar to how oscprompt does things. Or if you don't want to fetch metadata it's possible to get zynaddsubfx to serialize it out for you (currently supported oscdoc format as well as a json image which osc-bridge utilizes).

[zynmuse]

Thanks for the clarification. It's not really a problem. Its only the /out that I'm seeing without requesting. Everything is working extremely well.

FYI I am making use of the metadata. When the user first moves a control pot on zyn fusion I capture the path and create a structure to store the associated data in. I send a request for the metadata which currently I use for maximum and minimum range values, but my system also displays the short name. It was quite a revelation when I realized I could do that, it saved having to move the control pot fully one way then fully the other to capture the range.

Initially I had concerns about the amount of OSC traffic I'm likely to be adding, but in the event there doesn't appear to be a problem. It's useful to be able to intercept my midi stream, send any control/parameter changes followed immediately by the midi note (also over osc). That way in MOST CASES I only need to send control parameter data immediately before a note. zyn appears to process the data stream in the order it is received. In effect each note played can have different parameters to the previous note, allowing subtle changes to be incorporated , which is exactly what I was trying to achieve.

MOST CASES!

Parameters that can be changed just on a new midi note - oscillator parameters like wave shape. Changing these parameters once a note has been triggered has no effect on sound of that note so is wasteful of bandwidth.

There are some parameters which however need to be varied continuously ( between notes) such as filter parameters, volume levels. Suggestion: Currently the user has to make the decision which parameters these are in order not to vary them only on new note. It would be useful maybe if the metadata had some information regarding this so the optimum could be set up automatically without any user decision! eg- continuous/on new note.

John (Zynmuse)

[fundamental]

zyn appears to process the data stream in the order it is received.

Yep, that's the design goal, though there are some parameters which do result in out-of-order execution (e.g. some of the pad synth wavetable preparation).

It would be useful maybe if the metadata had some information regarding this so the optimum could be set up automatically without any user decision! eg- continuous/on new note.

No disagreement there, though the general trend is towards getting everything which reasonably can be a continuous parameter.

[zynmuse]

It would be a significant plus if the oscillator parameters were continuous!