Saving in the DSSI protocol

MusE is a MIDI/Audio sequencer with recording and editing capabilities, aiming to be a complete multitrack virtual studio for Linux. http://muse-sequencer.org/

Moderators: MattKingUSA, khz, spamatica

alex stone
Established Member
Posts: 137
Joined: Fri Jun 06, 2008 7:39 am

Saving in the DSSI protocol

Postby alex stone » Sun Feb 17, 2019 5:09 pm

Tim,
I remember briefly a conversation we had here about the lack of "saving" presets in DSSI, and the reference was using the LS16 gui as a linuxsampler dssi plugin.
I will admit i still don't understand this, and ask if you explain a little more.

Test case.
I open a synth track for DSSI LS16, and the track appears. I then have 2 gui options. LS16, which enables me to load a gig file per channel, for 16 channels. I do that. Then, because LS16 has no visible function to save/recall a preset, i close LS16, and open the Muse generic gui, which has the save/recall preset function. I save the preset in the generic gui, and as i've opened Muse3 from a terminal, i can see the gigs i chose have been loaded.

I then close the project without saving it, and open Muse again with a new project. I create a DSSI track with LS16, but use the generic gui, and attempt to load the preset i created.
Nothing.
The preset is there in my custom muse-preset directory, but it won't load. Is this a limitation in the DSSI protocol, or something to do with Muse not saving DSSI presets?

I intend to work with channels per instrument, not instrument maps as Program Changes. This is so i can "blend" different articulations together if required. (I've been working this way for many years)

The intent here is to create presets for every gig instrument i have in my audio samples box, then load and use only those i require for a particular project.



As an aside to this, but part of the workflow described above, can i submit a feature request for Track Templates.
Each track and all it's settings are saved as a preset which can be named, and groups of user selected tracks can be saved as well.
An example is a plugin track containing my instrument (DSSI/LV2) plus any midi tracks that send data to that track.

1st-violins instrument plus 16 midi tracks, all routed and saved as a "1st-violin" preset, which i can load in any project easily and quickly.

Thanks for listening,

Alex.

Tim E. Real
Established Member
Posts: 148
Joined: Sat Sep 15, 2012 12:36 am

Re: Saving in the DSSI protocol

Postby Tim E. Real » Mon Feb 18, 2019 8:51 pm

The preset is there in my custom muse-preset directory, but it won't load. Is this a limitation in the DSSI protocol, or something to do with Muse not saving DSSI presets?


G'day sorry for slightly late reply, lots going on...

The generic ui preset saving/loading feature only saves the control that you see inside the generic ui.
As far as I can see the LS DSSI plugin generic ui has no actual controls.
There is nothing to save or restore there :(

But... I have observed what I think is the same problem you are seeing:

Using LS LV2 everything tests fine :) I loaded two channels in QSampler, saved the MusE song, quit QSampler, restarted MusE (for fun)
and reloaded the song, opened QSampler et voila - both channels are preserved.
Using LS DSSI this is NOT happening for me. [Edit:] I observe the same thing happens in QTractor.

Can you move to LS LV2 plugins instead? It's... the way to go...

[Edit:] Be sure to use Dave's latest LV2 git, those LS related fixes he made for us several months ago may not yet be in a release.

I'm not sure if DSSI can support this type of thing. I'll have to check.
We store something called DSSI 'keys' which not many plugins use, except sometimes for recalling paths (Hexter et al).
[Yet another edit:] Tested Hexter: I stand corrected: It stores a bunch of keys, settings, and even custom patches! LS DSSI? Nothing.
Unless something is broken, I don't see any keys being given to us by LS DSSI (likely no paths involved in the traditional sense,
likely the LV2 version is able to store more detailed information required for this - full channels etc.).

We also store something called DSSI VST 'chunks' if you manually enable the support in the code (see top of dssihost.cpp)
But DSSI VST is a completely different story...
Maybe we should once and for all make that a cmake option, eh? Meh, DSSI VST is kinda dead though.

alex stone
Established Member
Posts: 137
Joined: Fri Jun 06, 2008 7:39 am

Re: Saving in the DSSI protocol

Postby alex stone » Tue Feb 19, 2019 7:19 am

Ok Tim, and thanks for testing this, i think i get it now.

I'll try and contact the dev of LS16 and see what he says about updating it and adding save and preset restore functions. I may also ask him if he can do the same sort of gui for LV2, as there isn't one currently that will allow using a gui for each instance of LV2. (We can only edit one instance at a time at the moment using Fantasia or Qsampler. Open, build, save, close instance, shutdown, startup, rinse, repeat, etc)

I'd be happy moving to LV2 permanently. It'd be a lot easier using a "normal" gui, which opens a window for each instance, which is why i'm experimenting with this and asking questions. :)

I'm building up a template at the moment to include everything, which is not ideal, but we have what we have. So far i have 17 LV2 instruments with 16 midi tracks per instance and Muse seem to be doing ok. Altogether i'll have about 60 or so instrument tracks plus all the associated midi tracks with a bit of trimming here and there, so we'll see what happens then. I'll keep you posted.


Ideally, as i wrote in the first post, some sort of track(s) template mechanism would take a lot of the hard work out of this, and enable users to load only the instrument/midi tracks they require for a particular project. I have a lot of sound "colour" instruments that i don't use all the time, so there's no need to load these by default, but be able to simply open that template if required.

Anyway, i'm enjoying the updates, thanks, and i'll keep testing and battering Muse3 and report back.

Alex.

Tim E. Real
Established Member
Posts: 148
Joined: Sat Sep 15, 2012 12:36 am

Re: Saving in the DSSI protocol

Postby Tim E. Real » Tue Feb 19, 2019 8:19 am

OK good to hear it works. I know it doesn't exactly aspire to the symphonic level of OOM, but here we are :wink:

Psst: In another branch, I am fixing up that stupid "Clip List Editor" that has remained brain dead for many years.
It is becoming... an actual Clip List! You know, Drag n' Drop clips into the project etc.

Good idea about tracks. We don't seem to have track presets or templates, do we? But we have complete song Templates...
Hm... Observations:
Probably the quickest route to a solution here is those song Templates.
As you may know we have song Templates which can do what you want but... when loaded they replace the currently loaded song :(

I believe with a few tweaks we can let users choose to add the loaded Template to the currently loaded song instead of replacing it.
Some of the tricky aspects we may encounter:
If the template contains synth tracks and they are assigned to Ports in the template, then if adding to an existing song
and the Port is already occupied we must find a different free Port for the synth instead of just overwriting,
since different templates might try to occupy the same Port with a synth.
Also we will have to ignore the template's midi configuration settings (if any) and use the settings in use by the currently loaded song.
And ignore a few other things I'm sure.
But right now I see it as... plausible.
Would this help?

[Edit:] Templates are just *.med song files in disguise. Therefore I suppose this feature would also allow
adding (loading) a complete song onto an already loaded song. We do a similar thing already with the "Import Midifile" command.

alex stone
Established Member
Posts: 137
Joined: Fri Jun 06, 2008 7:39 am

Re: Saving in the DSSI protocol

Postby alex stone » Tue Feb 19, 2019 8:59 am

Tim, we can try.

A suggestion and a question.

Save a synth/lv2 instance with the song template as a named instance. (linuxsampler-lv2 is renamed to 1st-violins for instance) When the song template is added to the base project it loads the "1st-violins" synth, which identifies as a unique port name. (If there's another synth port of the same name, Muse tells the user "does not compute" and prevents the synth port from being loaded, or automatically assigns the synth to the next free port)
I can see this taking care of any routing challenges as the associated midi tracks for that synth/song template already "see" the synth instance as the renamed "1st-violins" as saved in the template.

If the user wants a complete chain of midi tracks/synth-lv2/audio track, then audio tracks should be specifically named and saved in the song template as well. The audio track out may go to Master or to a buss in the base project, but that can be named too. The question for this i have is, if a instrument song template audio track is routed out to a buss, i.e. Master, and/or reverb buss, but other templates use the same buss, then can the template loading popup ask something like:

"This buss already has inputs assigned. Do you wish to route to the same inputs?"



Alex.


Return to “MusE Sequencer”

Who is online

Users browsing this forum: No registered users and 1 guest