ZynAddSubFX automatically Load Midi Learn? Get OSC port number from ZynAddSubFX?

[testcoockie]

First of all, ZynAddSubFX rocks, amazing sound and configurability.
Context of my question is below (*)

1) Does ZynAddSubFX have any command-line argument to Load Midi Learn data?
2) How can I easily get the connection port number from ZynAddSubFX to pass to oscprompt for the /connect command? Should I parse it from the console output or is there a better way? Can we force this port number to be the same number after booting the system?

(*)
I am creating a DIY headless version of ZynAddSubFX on Raspberry Pi 3 with Cirrus Audio Shield, with a OLED display, buttons and Midi Controller. For this, everything needs to be automatically booted: startx -> qjackctl -s -> zynaddsubfx -l myconf.xmz -> modified_oscpromt. This modified_oscprompt lets you set the master volume of ZynAddSubFX, select instruments and tweak parameters, similar to Midi Learn.

[fundamental]

1) Does ZynAddSubFX have any command-line argument to Load Midi Learn data?

Not yet, but it sounds like a good idea to add a flag to load it.
Does -M/--midi-learn=FILE.xlz sound like a reasonable option to you?

I think that the MIDI learn bindings should be stored in the .xmz format as well, but it's been a while since I've worked on that chunk of code.

2) How can I easily get the connection port number from ZynAddSubFX to pass to oscprompt for the /connect command? Should I parse it from the console output or is there a better way? Can we force this port number to be the same number after booting the system?

I'd say the best way is to use the -P/--preferred-port option to set the port that it should communicate over. There were some PID based files which kept track of some of this info, but IIRC they have been removed; So, if you don't set the preferred-port you'd need to parse it. Given your context I would expect the preferred-port to be exactly what you'd want.

I am creating a DIY headless version of ZynAddSubFX on Raspberry Pi 3 with Cirrus Audio Shield, with a OLED display, buttons and Midi Controller. For this, everything needs to be automatically booted: startx -> qjackctl -s -> zynaddsubfx -l myconf.xmz -> modified_oscpromt. This modified_oscprompt lets you set the master volume of ZynAddSubFX, select instruments and tweak parameters, similar to Midi Learn.

Nice. It seems there's been quite a few people trying this approach out since the remote OSC api has been added. I think this is the first time that I've heard about someone making use of oscprompt though. Heck this might be the first time I've seen someone mention that tool that wasn't immediately preceded by me trying to advertise it

[testcoockie]

Thanks for the fast reply.

Not yet, but it sounds like a good idea to add a flag to load it.
Does -M/--midi-learn=FILE.xlz sound like a reasonable option to you?

I think that the MIDI learn bindings should be stored in the .xmz format as well, but it's been a while since I've worked on that chunk of code.

Yes, such command-line option would be great, or adding it to the .xmz format. If you add it to the .xmz format, the separate load/save midi learn menu entries can be dropped I supposed, simplifying the GUI.

It would also be great if the selection of an instrument could be midi-learned. Midi-learn would start by middle-mouse click on an instrument. That way, it becomes very easy to switch between instruments, without using the GUI and without programming OSC.
Is that a feature you would consider?

[fundamental]

Yes, such command-line option would be great, or adding it to the .xmz format. If you add it to the .xmz format, the separate load/save midi learn menu entries can be dropped I supposed, simplifying the GUI.

Excellent. I should be able to add that in the next few days between some of the 3.0.0 UI bug fixing.

It would also be great if the selection of an instrument could be midi-learned. Midi-learn would start by middle-mouse click on an instrument. That way, it becomes very easy to switch between instruments, without using the GUI and without programming OSC.
Is that a feature you would consider?

I might consider it, but I would have to understand it a bit more.
Right now the standard bank select and program select messages are handled via MIDI, so it's already possible to swap instruments via MIDI without the UI.

Are you asking to add a feature where:
1. The user opens the bank UI
2. The user starts a midi learn action on a single entry (i.e. one instrument)
3. The user hits a physical MIDI button (i.e. a control that emits a MIDI CC which is either valued at 0 or 127)
4. The press of the button (cc_value=127) triggers a transition to that instrument
5. This learned MIDI CC => action can then be saved with other MIDI learned bindings

If this is/isn't what you're asking for, could you please clarify?

[testcoockie]

Yes, such command-line option would be great, or adding it to the .xmz format. If you add it to the .xmz format, the separate load/save midi learn menu entries can be dropped I supposed, simplifying the GUI.

Excellent. I should be able to add that in the next few days between some of the 3.0.0 UI bug fixing.

I thought about it a bit more: it seems that the Midi Learn feature and Load/Save Midi Learn is often specific to the chosen instrument. Aside from a command-line argument, it would be also useful to have a custom OSC command to load a Midi Learn feature: osc /load_patch and then osc /load_midi_assignments.
Another implementation would simply attach the midi learn to the patch, so that instrument and its midi assignments go together. Those are just some thoughts.

What do you think fits best with ZynAddSubFX? Or is this best left for a custom application (like a modified oscprompt).

I might consider it, but I would have to understand it a bit more.

Are you asking to add a feature where:
1. The user opens the bank UI
2. The user starts a midi learn action on a single entry (i.e. one instrument)
3. The user hits a physical MIDI button (i.e. a control that emits a MIDI CC which is either valued at 0 or 127)
4. The press of the button (cc_value=127) triggers a transition to that instrument
5. This learned MIDI CC => action can then be saved with other MIDI learned bindings
If this is/isn't what you're asking for, could you please clarify?

Yes, exactly.

Imagine a Midi controller as in the image below, and there is a Raspberry Pi 3 with ZynAddSubFX inside that midi controller, no screen. This rPi3 is prepared using Midi Learn with drum pads assigned to instrument selection. That would make a very nice stand-alone synthesizer for on the sofa or on-the-go.

IMG_1534.JPG

[fundamental]

Yes, such command-line option would be great, or adding it to the .xmz format. If you add it to the .xmz format, the separate load/save midi learn menu entries can be dropped I supposed, simplifying the GUI.

Excellent. I should be able to add that in the next few days between some of the 3.0.0 UI bug fixing.

Ok, the midi learn file load flag is now implemented in git.

I thought about it a bit more: it seems that the Midi Learn feature and Load/Save Midi Learn is often specific to the chosen instrument. Aside from a command-line argument, it would be also useful to have a custom OSC command to load a Midi Learn feature: osc /load_patch and then osc /load_midi_assignments.
Another implementation would simply attach the midi learn to the patch, so that instrument and its midi assignments go together. Those are just some thoughts.

What do you think fits best with ZynAddSubFX? Or is this best left for a custom application (like a modified oscprompt).

This general idea of midi button => OSC action would be a good extension of the midi learn system. Of course this isn't in place quite yet, so it might be easier to use the modified oscprompt for the moment.

I might consider it, but I would have to understand it a bit more.

Are you asking to add a feature where:
1. The user opens the bank UI
2. The user starts a midi learn action on a single entry (i.e. one instrument)
3. The user hits a physical MIDI button (i.e. a control that emits a MIDI CC which is either valued at 0 or 127)
4. The press of the button (cc_value=127) triggers a transition to that instrument
5. This learned MIDI CC => action can then be saved with other MIDI learned bindings
If this is/isn't what you're asking for, could you please clarify?

Yes, exactly.

Excellent, I'll try to add some generalizations in this vein when I have the chance.

[testcoockie]

Great, the new -M option works for me, thanks a lot.

I hit some small issue and wanted to report it in github, but the issue tracking is disabled?
Do you consider enabling it, or do you really want people to use the adds-infected sourceforge?
If I end up fixing it, would you accept pull requests on github?

The actual issue is: when trying to midi-learn the Effects volume encoder (Psysefxvol0), you get a segfault.
The Effects button is at the main screen (advanced and beginner), middle-mouse-click and rotate some midi controller and get this:

Code: Select all

residue message = <midi-add-watch>
Rtosc-MIDI: Cannot Learn address = </Psysefxvol0/part0>
Rtosc-MIDI: There are no min/max fields
Segmentation fault

Thanks!
Erwin

[fundamental]

I hit some small issue and wanted to report it in github, but the issue tracking is disabled?
Do you consider enabling it, or do you really want people to use the adds-infected sourceforge?

For the moment issues are only tracked on sourceforge.
This is partly because migration is an extra job to do and partly because I prefer that bugs and feature requests exist in different namespaces which isn't done on the github tracker.

If I end up fixing it, would you accept pull requests on github?

Pull requests are accepted on github

The actual issue is: when trying to midi-learn the Effects volume encoder (Psysefxvol0), you get a segfault.
The Effects button is at the main screen (advanced and beginner), middle-mouse-click and rotate some midi controller and get this:

Code: Select all

residue message = <midi-add-watch>
Rtosc-MIDI: Cannot Learn address = </Psysefxvol0/part0>
Rtosc-MIDI: There are no min/max fields
Segmentation fault

So, this is a bug in the rtosc MIDI mapping module.
From what I can tell a NULL pointer is being dereferenced around https://github.com/fundamental/rtosc/bl ... #L280-L286 (issues/pull requests/etc are enabled on that repo).
If you fix this, just submit the pull request on that repo and I'll update the submodule commit id in the zyn repo, otherwise I should get to this issue soonish.