Snapshot or "save" state for the LS backend.

You name it!
Post Reply
Alex
Moderator
Posts: 316
Joined: Wed Jan 23, 2008 9:08 pm

Snapshot or "save" state for the LS backend.

Post by Alex » Sun Nov 22, 2009 6:23 pm

I'm currently involved in an experiment to create a session manager driven from jack. So far so good, and early testing has been very positive. for the first time, we seem to be approaching a session management system that actually works.

It took as little as 11 lines of code to activate jack_session_notify save and quit functions for openoctave-midi, and it works, well.

My question related to the above is:

Can some sort of snapshot, or save state, be either activated, or implemented, in the LS backend? We're currently struggling with saving port connections going into and out of linuxsampler backend, as part of a session, to be opened again, restoring port connections. There's a further challenge with creating a save state up to the GUI (Fantasia in this case), and it may be more practical to consider implementing a save or snapshot function in the backend instead.
On top of that, some of us use only the backend, and the lscp file, not using a gui at all.

Is this feasible at all, or alternatively, is there already a mechanism in place to save the backend state, exclusive of a gui frontend?

The initial docs for the session project are here:

http://trac.jackaudio.org/wiki/WalkThro ... ackSession

Alex.

Andreas
Developer
Posts: 214
Joined: Sun Feb 03, 2008 8:33 am

Re: Snapshot or "save" state for the LS backend.

Post by Andreas » Sun Nov 22, 2009 9:14 pm

Alex wrote:Can some sort of snapshot, or save state, be either activated, or implemented, in the LS backend?
The plugins (LV2, VST and AU) save the state of the sampler. See src/drivers/Plugin.cpp, method Plugin::SetState and Plugin::GetState.

Alex
Moderator
Posts: 316
Joined: Wed Jan 23, 2008 9:08 pm

Re: Snapshot or "save" state for the LS backend.

Post by Alex » Sun Nov 22, 2009 9:32 pm

Andreas wrote:
Alex wrote:Can some sort of snapshot, or save state, be either activated, or implemented, in the LS backend?
The plugins (LV2, VST and AU) save the state of the sampler. See src/drivers/Plugin.cpp, method Plugin::SetState and Plugin::GetState.

Andreas, does this imply i can use the examples you've posted, even though i'm running LS standalone, and not as a plugin, to "link" to for any code from jacksession, and create a standalone save state?

Alex.

torbenh3
Newbie
Posts: 2
Joined: Sun Nov 22, 2009 9:45 pm

Re: Snapshot or "save" state for the LS backend.

Post by torbenh3 » Sun Nov 22, 2009 10:00 pm

hmm... this looks fine.
but it looks like i would need to copy the code to the jackdriver ?

why isnt there a common BaseClass for all drivers ?
i mean jack is an audio midi aggregate like a plugin basically.

any chance to sort this ?

Andreas
Developer
Posts: 214
Joined: Sun Feb 03, 2008 8:33 am

Re: Snapshot or "save" state for the LS backend.

Post by Andreas » Mon Nov 23, 2009 9:08 am

First I put the code in the VST as a test for the state saving functions of VST. Then, as I found it could be useful for other plugins, I put it in the abstract Plugin class.

So, sure, it can probably be moved one step further, to a class usable from standalone LS too.

torbenh3
Newbie
Posts: 2
Joined: Sun Nov 22, 2009 9:45 pm

Re: Snapshot or "save" state for the LS backend.

Post by torbenh3 » Mon Nov 23, 2009 10:55 pm

so how shall we proceed ?
i basically want to patch ls in the next couple of days. even if the session API is not stable yet,
it gives me some insights to patch apps.

iE the primary goal of the session approach is to keep these patches as small as possible,
so that
a) i can do lots of them myself.
b) app authors will do them quickly after reading the final announcement mail :-)

i dont know the ls code well enough to know how to change the class hierarchy in a meaningful way.
but i will read a bit.
but it would be nice to know what your approach would be, maybe i can do the patch right then :-)

supposed you move set state get state one class down. and plugin would derive from that.
what would derive from Plugin ?

maybe the standalone class could also just derive from Plugin ?
well... i need to read the code...

ccherrett
Advanced User
Posts: 162
Joined: Wed Jan 23, 2008 11:24 pm
Contact:

Re: Snapshot or "save" state for the LS backend.

Post by ccherrett » Wed Nov 25, 2009 11:29 pm

I am bumping this in hopes someone will answer who knows the answer.
Christopher Cherrett
Founder of The Open Octave Project
http://www.openoctave.org

User avatar
cuse
Developer
Posts: 366
Joined: Wed Jan 23, 2008 10:07 pm
Location: Germany

Re: Snapshot or "save" state for the LS backend.

Post by cuse » Fri Nov 27, 2009 10:21 am

The easiest and fastest way would be to move the two methods Plugin::GetState() and Plugin::SetState() (src/drivers/Plugin.cpp) into the main sampler class (src/sampler.cpp). The method names and everything can stay the same I think. The Plugin class would then use those two methods from the Sampler class instead. No need to read the LinuxSampler code base for that task.

I also thought about extending the current GetState()/SetState() code to dump and restore in LSCP format. So it can also be used by the LSCP server and thus dumped and restored remotely, but the same dump in LSCP format would on the other hand have a lot of redundancy and thus create larger dumps. So even if we add that later, I think the less redundant GetState() and SetState() methods and probably future LSCP dump methods can surely coexist side be side. So I would go with the simple solution I mentioned above.

Post Reply