Re: [LAD] Non Session Management
On 03/24/2012 11:09 PM, Fons Adriaensen wrote: On Sat, Mar 24, 2012 at 04:19:03PM +0100, rosea.grammostola wrote: More devs with an opinion? Fons, Torben, Paul, Emanual, ... ? I haven't used it so far (that is just a matter of limited time and priorities). But on reading the available docs my first impression is that there is some serious thinking behind this. There are quite a few features/choices that I do like/agree with. 1. The use of OSC, defining only the messages and leaving the actual implementation of the OSC interfaces to the application author. This instead of the all too common practice of imposing the use of some library that would integrate badly with the existing framework of an app, duplicate existing functionality or be in conflict with it, or pull in unwanted dependencies. 2. The use of jackpatch to manage jack connections instead of interfering with Jack itself. It's not clear from the specs, but if this means that NSM will (or can be told to) leave Jack completely alone I'll like it even more. 3. Clearly defining the way an app should behave w.r.t. its File menu entries (when managed). This is quite intrusive to existing clients, but it is IMHO absolutley essential. Kudos to the designer(s) for the having the courage to do this instead of allowing application developers to take the 'least effort' way (which would of course be better marketing, but invite later misery). At this point we can at least conclude that the people who have spoken out about session management and 'the modular approach' in the last couple of years and/or are involved in thinking about or building a session manager solution, agree more or less about the fact that NSM has a nice design and is probably useful in the different workflows. These people are, to name a few, Fons, Liles (author of NON) and Nedko (all though he thinks a session manager should do even more, that's what Ladish does. But ladish supports also JS and NSM (soon)). The JS developers didn't speak out clearly yet. What could be an advantage of JS, is that it has JACK as only dependency and is integrated in JACK. Others however, have pointed out that not depending on JACK is a big plus for them or even a demand. It gives more possibilities to have other apps in the session. As mentioned before, NSM seems to have some advantages JS doesn't have and lacks some disadvantages Ladish have (you need jackdbus). To call NSM a good compromise wouldn't give NSM the credits it deserves, but on the other hand, NSM could probably be a widely supported session API within the LAD/LAU community. This would be a unique situation. It's to early to settle down our conclusions though. It would be nice if more developers dive into it, study the API, study the practical implications, use NSM and probably even try to build a patch for it into their program, so we could have a better overview about how developers think about NSM. It could be that developers prefer a other session API then NSM. Maybe it's good to give your arguments. It's good to have disagreements and unity has it's disadvantages, but for an session API it's also good have agreements. Actually, you need enough of them to be successful as a Linuxaudio session API... Best regards, \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
Hey! I would like to ask. I did see a demonstration and it looks really nice. However, am I right in understanding that currently only several apps are really supported? And if this is true - is there an option of adding support for more apps? -- Louigi Verona http://www.louigiverona.ru/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On 03/26/2012 05:51 PM, Louigi Verona wrote: Hey! I would like to ask. I did see a demonstration and it looks really nice. However, am I right in understanding that currently only several apps are really supported? And if this is true - is there an option of adding support for more apps? The API is explained on this website: http://non.tuxfamily.org/nsm/API.html Developers can build patches for their software to support NSM, as they can do for JS and Ladish. At the moment only non-daw, non-seq, non-mixer and yoshimi (patch available). Atm their are more applications with JS support (Ladish supports ladi, JS and NSM): http://tangostudio.tuxfamily.org/en/packages/unstable But the development of JackSession API has more or less stopped because of the fact that Torben has no time for Linuxaudio atm. Also it's not realistic to expect many efforts from Paul in this area. Moreover, NSM seems to have features JS lacks, but which could be a plus when it comes to workflow (stop session, copy session, more easy to add apps without session support into the session, possible to add apps without JACK support to the session). Also some people (Fons, Liles, Nedko) think that JS has it's limitations and therefore they don't support it (Fons, Liles). NSM could gain wider support probably. At first sight, NSM looks to me more promising then JS does, e.g. it has more chance to become really useful and to get broad support in the community (from the 'modular diehards'). But this is just a personal feeling/ thought. If this is really the case, depends on the view of the LAD community. \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
more easy to add apps without session support into the session How is that done? On Mon, Mar 26, 2012 at 7:15 PM, rosea.grammostola rosea.grammost...@gmail.com wrote: On 03/26/2012 05:51 PM, Louigi Verona wrote: Hey! I would like to ask. I did see a demonstration and it looks really nice. However, am I right in understanding that currently only several apps are really supported? And if this is true - is there an option of adding support for more apps? The API is explained on this website: http://non.tuxfamily.org/nsm/** API.html http://non.tuxfamily.org/nsm/API.html Developers can build patches for their software to support NSM, as they can do for JS and Ladish. At the moment only non-daw, non-seq, non-mixer and yoshimi (patch available). Atm their are more applications with JS support (Ladish supports ladi, JS and NSM): http://tangostudio.tuxfamily.**org/en/packages/unstablehttp://tangostudio.tuxfamily.org/en/packages/unstable But the development of JackSession API has more or less stopped because of the fact that Torben has no time for Linuxaudio atm. Also it's not realistic to expect many efforts from Paul in this area. Moreover, NSM seems to have features JS lacks, but which could be a plus when it comes to workflow (stop session, copy session, more easy to add apps without session support into the session, possible to add apps without JACK support to the session). Also some people (Fons, Liles, Nedko) think that JS has it's limitations and therefore they don't support it (Fons, Liles). NSM could gain wider support probably. At first sight, NSM looks to me more promising then JS does, e.g. it has more chance to become really useful and to get broad support in the community (from the 'modular diehards'). But this is just a personal feeling/ thought. If this is really the case, depends on the view of the LAD community. \r -- Louigi Verona http://www.louigiverona.ru/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On 03/26/2012 06:21 PM, Louigi Verona wrote: more easy to add apps without session support into the session How is that done? On Mon, Mar 26, 2012 at 7:15 PM, rosea.grammostola rosea.grammost...@gmail.com mailto:rosea.grammost...@gmail.com wrote: On 03/26/2012 05:51 PM, Louigi Verona wrote: Hey! I would like to ask. I did see a demonstration and it looks really nice. However, am I right in understanding that currently only several apps are really supported? And if this is true - is there an option of adding support for more apps? The API is explained on this website: http://non.tuxfamily.org/nsm/__API.html http://non.tuxfamily.org/nsm/API.html Developers can build patches for their software to support NSM, as they can do for JS and Ladish. At the moment only non-daw, non-seq, non-mixer and yoshimi (patch available). Atm their are more applications with JS support (Ladish supports ladi, JS and NSM): http://tangostudio.tuxfamily.__org/en/packages/unstable http://tangostudio.tuxfamily.org/en/packages/unstable But the development of JackSession API has more or less stopped because of the fact that Torben has no time for Linuxaudio atm. Also it's not realistic to expect many efforts from Paul in this area. Moreover, NSM seems to have features JS lacks, but which could be a plus when it comes to workflow (stop session, copy session, more easy to add apps without session support into the session, possible to add apps without JACK support to the session). Also some people (Fons, Liles, Nedko) think that JS has it's limitations and therefore they don't support it (Fons, Liles). NSM could gain wider support probably. At first sight, NSM looks to me more promising then JS does, e.g. it has more chance to become really useful and to get broad support in the community (from the 'modular diehards'). But this is just a personal feeling/ thought. If this is really the case, depends on the view of the LAD community. \r On 03/26/2012 06:21 PM, Louigi Verona wrote: more easy to add apps without session support into the session How is that done? You are able to start the client via the Non Session Manager GUI. If you need to add arguments to the client, you can do this via a script using the exec command. Liles is going to write a proxy app to make this more easy. With the client jackpatch you can make the connections. You have to manually save the clients who doesn't support NSM in this situation. Iirc this is also possible with JackSession, but it's not implemented in Qjackctl and I'm not sure how this works at the end. At least in NSM it seems to be more easy, with a nicer workflow. hth \r Regards, \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
Am 26. März 2012 17:15 schrieb rosea.grammostola yoshimi (NSM patch available). Where to find the NSM patch for yoshimi ? -- E.R. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On Mon, Mar 26, 2012 at 11:15 AM, Emanuel Rumpf xb...@web.de wrote: Am 26. März 2012 17:15 schrieb rosea.grammostola yoshimi (NSM patch available). Where to find the NSM patch for yoshimi ? http://non.tuxfamily.org/nsm/yoshimi-nsm.patch ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
Hi Rosea, can you elaborate how do you use arguments with clients using exec? Can you post here an example with yoshimi just to name an application supported in NSM? is there any document where to read more about NSM other than http://non.tuxfamily.org/nsm/ ? Thanks for your help. Diego 2012/3/26 rosea.grammostola rosea.grammost...@gmail.com On 03/26/2012 06:21 PM, Louigi Verona wrote: more easy to add apps without session support into the session How is that done? On Mon, Mar 26, 2012 at 7:15 PM, rosea.grammostola rosea.grammost...@gmail.com mailto:rosea.grammostola@**gmail.comrosea.grammost...@gmail.com wrote: On 03/26/2012 05:51 PM, Louigi Verona wrote: Hey! I would like to ask. I did see a demonstration and it looks really nice. However, am I right in understanding that currently only several apps are really supported? And if this is true - is there an option of adding support for more apps? The API is explained on this website: http://non.tuxfamily.org/nsm/_**_API.htmlhttp://non.tuxfamily.org/nsm/__API.html http://non.tuxfamily.org/nsm/**API.htmlhttp://non.tuxfamily.org/nsm/API.html Developers can build patches for their software to support NSM, as they can do for JS and Ladish. At the moment only non-daw, non-seq, non-mixer and yoshimi (patch available). Atm their are more applications with JS support (Ladish supports ladi, JS and NSM): http://tangostudio.tuxfamily._**_org/en/packages/unstable http://tangostudio.tuxfamily.**org/en/packages/unstablehttp://tangostudio.tuxfamily.org/en/packages/unstable But the development of JackSession API has more or less stopped because of the fact that Torben has no time for Linuxaudio atm. Also it's not realistic to expect many efforts from Paul in this area. Moreover, NSM seems to have features JS lacks, but which could be a plus when it comes to workflow (stop session, copy session, more easy to add apps without session support into the session, possible to add apps without JACK support to the session). Also some people (Fons, Liles, Nedko) think that JS has it's limitations and therefore they don't support it (Fons, Liles). NSM could gain wider support probably. At first sight, NSM looks to me more promising then JS does, e.g. it has more chance to become really useful and to get broad support in the community (from the 'modular diehards'). But this is just a personal feeling/ thought. If this is really the case, depends on the view of the LAD community. \r On 03/26/2012 06:21 PM, Louigi Verona wrote: more easy to add apps without session support into the session How is that done? You are able to start the client via the Non Session Manager GUI. If you need to add arguments to the client, you can do this via a script using the exec command. Liles is going to write a proxy app to make this more easy. With the client jackpatch you can make the connections. You have to manually save the clients who doesn't support NSM in this situation. Iirc this is also possible with JackSession, but it's not implemented in Qjackctl and I'm not sure how this works at the end. At least in NSM it seems to be more easy, with a nicer workflow. hth \r Regards, \r __**_ Linux-audio-dev mailing list Linux-audio-dev@lists.**linuxaudio.orgLinux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/**listinfo/linux-audio-devhttp://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
I've been able now to launch the NON session-manager. - by writing an own simple build-script. ( is my system borked ? or just cmake ?) I have to say, I'm counting me as a fan of J. Liles Software. Somehow I agree with his style, I would described as unbloated, but still pragmatic and effective. - - - In my opinion NSM is the best approach to session management so far and I'm encouraging every audio-app dev. to jump on this train ! It is non-intrusive, has the required functionality. - - - There some minor things, I'd like to see: - sessions should have an option to optionally restore window-position and -size of client apps too (would this work for workspaces as well, possibly xinerama ?) - tools as nsmd, jackpatch, osc_send should show a help message, when started from command line. - the session-manager should have an additional help button, showing a window describing the possible actions (how to duplicate a session, work with templates) - just like non-seq has a window for key-strokes. - in the session-man. there should be a hint where the data is stored. I'd like to always know where it is. Questions remaining: - where would audio apps store large (audio) files ? a custom path ? - appart from large files (audio), all configuration should go to the instances session folder - right ? - where is the integrated chat client ? ;) Possible Bugs - although jackpatch is loaded, some connections (jack-midi) are not restored here, switching from one to another session (while the jack-audio-connection is being done) - switching from one session with yoshimi to one without it closes yoshi however: switching from a session with two non-seq instances to a session with only one non-seq instance doesn't close the second instance Once this is bug-free, this session-manager is a real enrichment to the audio community ! There's almost a fun-factor using it. I'm going to spend my time switching sessions soon. :) Thanks to Jonathan. -- E.R. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] LV2-C++-Tools
Shared data plus locking is a pretty crap model in general, really. When people talk about all the complications that threads introduce, they're really talking about this. Shared mutable state is the cancer of multi-threaded programming. This should be tattooed on every newbie. ;) Visualize your GUI running on a 64-bit iPad in Madrid, and your DSP running on 32-bit Ubuntu in Seattle. Design your API accordingly. Best Regards, Jeff ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
Am 26. März 2012 22:17 schrieb Diego Simak diego.si...@gmail.com: is there any document where to read more about NSM other than http://non.tuxfamily.org/nsm/ ? There is http://non.tuxfamily.org/nsm/API.html In the source package, there is some documentation too ! Finally there is always the source code :) Thanks for your help. Diego Thanks for interest. -- E.R. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
Thank you, I will try to bite the source code ;-) I want to say that I was trying NSM yesterday and I'm very impressed by it's simplicity and (a no minor point) it's desing from the graphical point of view. I want to say that I'm very impressed by the thoroughness of the documentation, something that I always admire. From the **USER** point of view I had tried Jack Session and LASH (a long time ago when it was a requirement with FST) and by now NSM (a bit hasty decision) is in the 1st place. Maybe now it's the time that people involved in LAD (I'm just a user with a little code experience, but I can help in any way) just try to document the advantages and disadvantages about Jack-session, LASH, LADISH, Scripts, NSM in http://jackaudio.org/persistent_connections, or maybe in the Jack Wiki just like the Jack1 and Jack2 comparison document that was included some time ago. I think that it could help devs and users as well to get a picture of the current Session Managment world in JACK. Thanks for this great peace of software. Diego 2012/3/26 Emanuel Rumpf xb...@web.de Am 26. März 2012 22:17 schrieb Diego Simak diego.si...@gmail.com: is there any document where to read more about NSM other than http://non.tuxfamily.org/nsm/ ? There is http://non.tuxfamily.org/nsm/API.html In the source package, there is some documentation too ! Finally there is always the source code :) Thanks for your help. Diego Thanks for interest. -- E.R. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On Mon, Mar 26, 2012 at 10:32:38PM +0200, Emanuel Rumpf wrote: - where would audio apps store large (audio) files ? a custom path ? That is something that needs to be looked at. In my use cases it is very common for several projects to use the same recorded tracks, and that could be a few gigabytes. When using non-destructive editing these are de facto read-only, so they can be shared. An app can always cheat the SM. Even if the SM forbids symbolic links in a session directory, all it takes for an app is saving a directory path as part of the current configuration. But it would be better if the SM were aware of the existence of such data, so that it could e.g. show of list of it upon request. This would then require apps to explicitly declare paths to external data. It would probably be a rather simple extension to NSM. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On 03/26/2012 10:32 PM, Emanuel Rumpf wrote:
I've been able now to launch the NON session-manager.
- by writing an own simple build-script.
( is my system borked ? or just cmake ?)
cmake, iirc it's just ./configure, make, make install
I have to say, I'm counting me as a fan of J. Liles Software.
Somehow I agree with his style,
I would described as unbloated, but still pragmatic and effective.
- - -
In my opinion NSM is the best approach to session management
so far and I'm encouraging every audio-app dev. to jump on this train !
It is non-intrusive, has the required functionality.
All though I think I share your opinion here, I do realize that
developers jumped on trains before... I can also imagine some
frustration if you just added JS to your app and now this new train is
coming by. That's why a close research on the characteristics,
advantages and disadvantages is important imo. If at the end NSM it as
good as it looks, we can jump on that train together without hesitation.
We have to be sure somehow that this is a train which takes us where we
want to be (blue water with a yellow beach), in such a way that we don't
need another train afterwards to be able to reach our destination.
- - -
There some minor things, I'd like to see:
- sessions should have an option to optionally restore window-position
and -size of client apps too (would this work for workspaces as well,
possibly xinerama ?)
I use fluxbox for this.
- tools as nsmd, jackpatch, osc_send should show a help message,
when started from command line.
- the session-manager should have an additional help button, showing a
window describing the possible actions (how to duplicate a session,
work with templates) - just like non-seq has a window for key-strokes.
- in the session-man. there should be a hint where the data is stored.
I'd like to always know where it is.
Questions remaining:
- where would audio apps store large (audio) files ? a custom path ?
- appart from large files (audio), all configuration should go to the
instances session folder - right ?
- where is the integrated chat client ? ;)
Possible Bugs
- although jackpatch is loaded, some connections (jack-midi) are not
restored here,
switching from one to another session (while the jack-audio-connection
is being done)
Known bug, should be better in git ('next branch'??)
- switching from one session with yoshimi to one without it closes yoshi
however:
switching from a session with two non-seq instances to a session
with only one non-seq instance
doesn't close the second instance
Once this is bug-free,
this session-manager is a real enrichment to the audio community !
There's almost a fun-factor using it. I'm going to spend my time
switching sessions soon. :)
I do share your optimism, but I don't want to celebrate to early this
time...
Regards,
\r
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On Mon, 2012-03-26 at 21:40 +, Fons Adriaensen wrote: [...] An app can always cheat the SM. Even if the SM forbids symbolic links in a session directory Which would be an extremely terrible idea, because... it would be better if the SM were aware of the existence of such data ... it is the best way of achieving this This would then require apps to explicitly declare paths to external data. ... because it doesn't require this, and is thus the only solution that will nest correctly. -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] LV2-C++-Tools
On Tue, 2012-03-27 at 09:37 +1300, Jeff McClintock wrote: Shared data plus locking is a pretty crap model in general, really. When people talk about all the complications that threads introduce, they're really talking about this. Shared mutable state is the cancer of multi-threaded programming. This should be tattooed on every newbie. ;) Visualize your GUI running on a 64-bit iPad in Madrid, and your DSP running on 32-bit Ubuntu in Seattle. Design your API accordingly. Indeed. With respect to plugins, I deeply regret it's even *possible* to do otherwise, but unfortunately sometimes reality gets in the way :) -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On Mon, Mar 26, 2012 at 2:40 PM, Fons Adriaensen f...@linuxaudio.orgwrote: On Mon, Mar 26, 2012 at 10:32:38PM +0200, Emanuel Rumpf wrote: - where would audio apps store large (audio) files ? a custom path ? That is something that needs to be looked at. In my use cases it is very common for several projects to use the same recorded tracks, and that could be a few gigabytes. When using non-destructive editing these are de facto read-only, so they can be shared. An app can always cheat the SM. Even if the SM forbids symbolic links in a session directory, all it takes for an app is saving a directory path as part of the current configuration. But it would be better if the SM were aware of the existence of such data, so that it could e.g. show of list of it upon request. This would then require apps to explicitly declare paths to external data. It would probably be a rather simple extension to NSM. Fons, I'd like to hear more about this use case. Currently one of the strong points of NSM is that applications with heavy state (e.g. large audio files) know *exactly* where to put the state at the time they join the session. This eliminates the need for undesirable hacks with just storing a link to the heavy state (as was generally required with LASH). I felt like this was one of the primary requirements of Non-DAW which was not addressed by other session managers. But as far as sharing heavy state between multiple clients in a session, I have not considered the issue. It is certainly possible to permit something like that, and even as it is right now two clients could work something out peer-to-peer using the NSM server's 'broadcast' capability. If several different sessions need to share the same data, then I would say that it's reasonable just to have it stored outside of the session root, preferrably symlinked from within the session so that it could be picked up by a simple archiving process. Perhaps someone in a situation like this might also consider using some kind of deduplicating filesystem to store their data and remove the complexity to the systems level. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On Tue, 2012-03-27 at 01:04 +0200, Emanuel Rumpf wrote: I'm trying to figure out different use cases: - an app loads an audio file (reference to orig file) ---possibility: file moves - ref. has to be adjusted - the app is non-destructive, for changes, a copy is produced (where?) - the session is being duplicated - the new session keeps the refs to original audio files, (but creates copies, for files which have been modified ?? or refer.s them too ? refs. them too, I suggest. ) The problem here is, that files could quickly distribute (and cross-link) over MANY different directories. Maybe a common directory for all audio-files modified by ANY session-capable application instead ? pros: For all instances, we knew at least their files location. Different instances could link to the same file (creating a new copy, only when modifying) This exact problem came up when I set out to implement non-destructive plugin state saving in Ardour, with support for plugins referring to files (e.g. loaded samples). The obvious basic solution in a non-destructive context is to save each snapshot to its own directory. The tricky bits come when you have links in that directory to files. What you end up with is a few directories with specific roles. I'll try to document the path leading to this as tersely as possible. The plugin/host situation is analogous to app/SM, very closely with respect to what's on disk, not so much with respect to responsibilities and such. There are two kinds of file: * External files, e.g. something you loaded from the filesystem somewhere. There are assumed to be immutable. * Files created by the plugin, which may be different each save As I have said a few times on this list, for various reasons I think straightforward and transparent symlinks are the best way to refer to external files. I'll just take this as given/obvious and not bother rehashing the argument (erecting a bunch of protocol and/or file format junk only *adds* problems). So, you want to save state, and the plugin refers to a bunch of files. As mentioned above, this can mean a lot of references to one file. Since these could be massive, redundant copies must never happen at all. For ease of moving things, or resolving them if they break, we want a minimal number of actual links to an external file, i.e. 1 (this is also necessary for archival, see below). So, we don't want every single state snapshot directory to have a link to /media/bigfile.wav. To avoid this, make a directory specifically for all links to external file, and link to those links instead. This localizes all links to files outside the session. The other case is files written to during execution, e.g. recorded waveforms. Here, on each save, you need to check if the file is actually any different, and make an actual copy if so (so the original can continue to be used) in the state snapshot directory. During run time, all the created files live in a scratch directory, which you can preserve, or just throw out when you close since copies have been made for every snapshot. Working with the requirement that the plugin's file namespace must not be messed with (e.g. if you save foo.wav to your state directory, it should actually be called foo.wav), you end up with: 1) The file directory. This is where the plugin creates files, whenever. It can be considered run-time scratch. 2) The copy directory. This is where copies of things in the file directory are made, to preserve their state at a particular instant in time. This mirrors the structure of the file directory, but appends .2 or .3 etc. for the various snapshots of a file 3) The save directory. This is the directory of a particular state snapshot. It can contain whatever. 4) The link directory. This is where all links to external resources live. Any state snapshot that refers to an external file actually links to a link here. This is in the Lilv API. It might seem complicated, but it is only optionally this powerful, if you don't care about non-destructive saving or avoiding copies you can simply use one directory for everything. I think I can make a reasonable argument that this is the minimal number of directories that meet the desired requirements: A) The file directory and copy directory can not be the same directory, because the copies would pollute the plugin's file namespace and possibly clash. It would also make it difficult to know what files are actually needed by the session, since some may be scratch. The files directory is unique in that its contents may be safely deleted. B) The copy directory and save directory can not be the same directory, since multiple saves may refer to the same file with the same state. Without the copy directory this would require two copies of the same file. C) The link directory must be separate to avoid having a large number of links to the same external file. This is convenient in general (only one link to potentially
Re: [LAD] LV2 specification packaging
On Thu, 2012-03-22 at 22:15 +, Chris Goddard wrote: I like the idea of an overall version number, so, LV2 V2.1 is released which contains foo v0.7, ba v1.1, thing v0.4. Over time foo is updated to v0.8, LV2 V2.2 gets released. Done. With respect to pkg-config, the lv2core package will remain, for compatibility. Otherwise, there is just an lv2 package. Configure scripts can just check whatever version of that. Generally, APIs should have meaningful version numbers, but I can't come up with a scheme for this. People seem to not like the date thing, though, so lv2 currently has the completely arbitrary version 0.1.0. I guess I will just increment whichever digit I arbitrarily feel like incrementing that day... Developers currently following the bleeding edge should dump all their extension specific pkg-config checks and simply check for 'lv2'. The price of this change is minimal sympathy for stagnant crap: the benevolent dictator model will indeed keep things more agile and unified, but only if you keep up. -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
