On 03/22/2012 01:33 PM, rosea.grammostola wrote: One thing to add to the discussion: To me it looks like NSM has some features JackSession was criticized for, quit session, lack of support for non-supported audio apps, multiple sessions. And it doesn't have the features Ladish was criticized for (need for jackdbus).

On Thu, Mar 22, 2012 at 12:33 PM, rosea.grammostola < rosea.grammostola(a)gmail.com&gt; wrote: JackSession is merged in JACK. No external dependencies, if all other session management systems would integrate with it, then the problem would be solved. I appreciate that there are things that JackSession cannot currently do, but IMO there's a lot to be gained from widespread adopting of JackSession. When I find time to implement restoring sessions in Luppp, the functionality will be available trough JackSession. -Harry

On March 22, 2012 4:42:55 PM rosea.grammostola wrote: Our MusE allows running without Jack, using a dummy audio driver and ALSA for midi. Some folks run it that way. (I was told MusE had an ALSA audio driver long ago, I was thinking of toying with that again to help get users running. A recent post on jack-dev lamented the lack of ALSA audio support in several apps, including ours.) So I've often wondered whether we should try to add JS support. I think for us, we still need a SM that works with and without Jack. We've always had LASH support. With LADISH LASH emulation, maybe we won't have to do anything... for now. I remember early threads about NON internals, it seemed to have smart design. Cheers. Tim.

On Thu, 2012-03-22 at 12:59 +0100, thijs van severen wrote: [...] I am not sure what you are asking. LV2 has state saving (in the works anyway, but implemented by several things now), which should be implementable by any plugin and host, and will mesh fine with session management. It is simpler than application session saving, naturally, since there's just a few functions called directly. -dr

On 03/22/2012 04:10 PM, David Robillard wrote: Thanks David. More devs with an opinion? Fons, Torben, Paul, Emanual, ... ? \r

On 03/24/2012 11:09 PM, Fons Adriaensen wrote: 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

On 03/26/2012 05:51 PM, Louigi Verona wrote: 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

On 03/26/2012 06:21 PM, Louigi Verona wrote: 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

Am 26. März 2012 22:17 schrieb Diego Simak &lt;diego.simak(a)gmail.com&gt;om>: 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 interest. -- E.R.

Am 26. März 2012 17:15 schrieb rosea.grammostola Where to find the NSM patch for yoshimi ? -- E.R.

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.

On Mon, 2012-03-26 at 21:40 +0000, Fons Adriaensen wrote: [...] Which would be an extremely terrible idea, because... ... it is the best way of achieving this ... because it doesn't require this, and is thus the only solution that will nest correctly. -dr

On Tue, 2012-03-27 at 01:04 +0200, Emanuel Rumpf wrote: 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 fix), but required for archival. An archival tool (e.g. tar -h) would actually copy the file to the links location. Without the link directory this would produce an archived session with many copies of the same (possibly massive) file. D) The save directory is inherently where one save takes place, its existence is a given. Figuring this all out was a long process of trial and error, but now that I write it down it seems clear it can't be simplified without failing to meet a requirement. I am all ears for arguments to the contrary, though. This scheme would need some slight tinkering to tolerate external files that change, but this would require keeping copies of system files around just in case, not just when you archive. That is, ANY external files used EVER would have to be copied in case they change. I don't think this is acceptable, and plugins have no business modifying external files anyway. Apps that want to get fancy and share files may want a solution to this, but particularly since shared mutable files is almost certainly crazy anyway, one app should simply "own" any such files. It may tell other hosts about them if it pleases, possibly via OSC. I don't think the session manager itself should be bloated out with a bunch of unnecessarily shared file database stuff to support a rather esoteric ability that can easily be achieved without doing so. In other words, if apps want to talk to each other and share file paths, that is their business. -dr

On Tue, 2012-03-27 at 14:24 +0200, Emanuel Rumpf wrote: I am having a hard time imagining anything *less* likely to be adopted than trying to cram a *database* down everyone's throats to save some files! ;) I think I'll just avoid going into the why and say: not in a million years. What if a file is deleted? What if the entire file system is wiped? Users can remove files, film at eleven. Nothing to do with symlinks. So? Apps can store whatever they way. If you are crazy and want to store a binary database in there instead of a sane file format, feel free. No session manager that forces everyone to use some database would ever fly. This is obvious. That is inherent to any solution with "links" to external resources. Links to external resources are a requirement. If you want to move a session, use a smart tool that can fix the links, or archive it. The argument for these having to be separate is because otherwise the copies would pollute the namespace. Also remember files can be created before save time. A file outside the session is a file outside the session. Happening to be in a directory that happens to be a different session makes no difference. You keep bringing up this "what if the user deletes a file that is used" problem as if there could possibly be a solution. Obviously there can not be. Yep, users can delete files. That is not a criticism of any particular solution. In reality this is not a problem. Users have a pretty good idea that if they go screwing around with e.g. their ardour session and start deleting files, something is probably going to break. Don't Do That. Why? What exactly is "large"? Just because a file is large doesn't mean I don't want it in a session. It is a requirement to be able to roll up a self-contained archive of a session *if* you want to. Why? It's perfectly clear. A file is a file. Doesn't really matter. You can use one. You can use many. Whatever. And why does the Grand Centralized Session Manager File Authority need to do this? What exactly is the problem that all these rules and authority solve? The only thing you need to be able to clean up is the location of the latest snapshot, or the snapshots you want to keep. The rest is a classic garbage collection. You do not need a blessed centralized file location for this. It doesn't even make it any easier. To be honest I don't think this dissection of the problem really makes much sense. Basically in a quest to have a database for a database's sake you've merged all the directories, requiring a database or at least index file to keep track of all the special different "kinds" of files in there, and requiring a big fancy session manager to actually do all of this. In the process nothing has been won. Nobody ever got fired for using hierarchical directory structures with files in them. KISS. -dr

On Wed, 2012-03-28 at 14:11 +0200, Emanuel Rumpf wrote: [...] In addition to not being archivable by any archive tool, and not transparent to file system tools, anything but normal files means you don't have normal app state in the session anymore, but need some kind of mechanism to ask for every single file. This means loading code gets weird and depends on the session manager, and the app's session format also depends on whether or not it was saved with the session manager. Apps are not going to go for that, period. It should be obvious by now that a prerequisite for a session manager that is actually going to be adopted is it doesn't ram a bunch of annoyance down implementer's throats. Any such annoyance needs a very compelling argument to counteract that. I don't see one here. A sufficiently "compelling" argument would be something important that works that could not work without all the additional junk. -dr

On Mon, Mar 26, 2012 at 05:15:09PM -0700, J. Liles wrote: You may have misread what I wrote, it's not about data shared between clients in a single session (but that is an interesting twist that I havent' considered so far). It's a about essentially read-only and possibly huge data sets shared between sessions. Given a multitrack recording, I may be required to make a 3rd order Ambisonic mix originally, another for some discrete speaker set used at a concert some months later, and a Wave Field Synthesis one at any time. They all use the same recorded and edited tracks, but the tools and methods used are completely different in each case, and I would really not want to combine them into a single session. If only because someone using any of these forms should not be required to have the tools for all the other ones. Nor would I want the the shared data to be duplicated - not only because it's a wast of disk space, but also because it may be reviewed and modified as well (e.g. correcting bad edits) and such changes should be picked up by all sessions using the data. My POV about 'external' data (that is data not saved as part of a session) is that if the user (or an app on behalf of the user) declares that some data is external to the session then the SM should just accept this as a fact an go on doing its thing. It is then of course the user's responsability to take care of such data if a session is transferred or archived. I would expect a SM to have a tool to 'ls' a session (providing a list of required apps etc.), and ideally such a tool should be able to mention any dependencies on external data. Using symlinks is indeed a simple solution, at least on Unixy systems. It provides the required functionality, archiving tools usually can be told to follow symlinks or not, and to the SM any symlink in a session directory is an indication of 'external' dependencies. And it doesn't require any extensions to the SM protocol - creating a symlink is a declaration of external data. 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)

A second scenario The simple one (simple for the SM, not for the apps): - applications decide themself how to handle large-files - but still tell the SM about all files currently used, when the session is saved This allowed the SM to: - tell the user if a certain file is part of any session registered at the SM - export all files used by a session - optionally, either as symlinks, or as copy to a specified directory - verify and warn, if a referenced file is missing (although, maybe this should be left to the app then too) Would this suffice ? -- E.R.

Am 28. März 2012 05:46 schrieb David Robillard &lt;d(a)drobilla.net&gt;et>: The reason is simple and important: Duplicating a session should be lightweight. Lfiles _belong_ to _one or many different_ sessions, but they would not be stored within the session folder. Instead, a cloned session would contain references to _the same_ Lfiles, as its original ! This means, no Lfiles are copied, just referenced, thus its a quick procedure. This is no problem, if applications are non-destructive: If the clone had to change a file, it would create a copy in the Lfiles directory and use this new reference. For destructive apps, this woulde not work obviously and the SM would have to duplicate their files in the Lfiles directory too. What is a large-file ? (for a non-destructive app) Every file, that is not required to immediately become copied if a session has to be cloned. Every file, where a reference is enough in the first place. What is NO-large-file ? Data that is required to access large-files (references), or that is lightweight (~below 1MB) (some config-values), or has to be read by the SM to initialize the client. -- E.R.

2012/3/28 Emanuel Rumpf &lt;xbran(a)web.de&gt; this all sounds really interesting, but IMHO these are all extras (that can introduce a lot of extra complications) if i can tell the SM where the session needs to be stored that's enough for me. i really dont care how the underlying files/dirs are organised all i care about is that i can save/restore a session. and if this comes at the price of HD space, so be it if i know where the sessions are stored it's easy enough to archive the complete dir and move it to a fileserver thijs -- follow me on my Audio & Linux blog <http://audio-and-linux.blogspot.com/> !

On Wed, 2012-03-28 at 18:31 +0200, Renato wrote: [...] The mentioned functionality does not depend on a centralized file store. That's the point I'm trying to make, it's not "complexity that wins us a bunch of nice features", it's just complexity. At most what is required for some of them is the session manager know about registered /sessions/. This is a dramatically different thing than building a prison for all /files/. While not bulletproof (you could have sessions on a removable drive), it's not really a problem because it doesn't impose anything on apps. Lack of a centralized file store does not mean large files would be duplicated. -dr

On Wed, 2012-03-28 at 20:00 +0200, Emanuel Rumpf wrote: It's sooo complicated because it forces everything involved to use a special file finding and/or loading interface. It also requires that central store to remain consistent, which is roughly infinity times harder than... well, not. Any program that deletes files based on some fantasy of omniscience isn't one I'm trusting with my data. Actually I think I'd take that a bit farther and say I don't want a session manager deleting files at all. Ever. -dr

On Thu, 2012-03-29 at 15:29 +0200, Emanuel Rumpf wrote: In order to do anything useful, most obviously archive, the SM needs the ability to change those paths. The only realistic way of achieving this is via links. Otherwise you would have to design a "move files" protocol, and in order to archive/move/etc you'd have to launch every app and use that protocol to manipulate the session state, because the SM doesn't know every program's file format. Not only is that a huge implementation burden on apps, it's clunky and fragile; a big silly mess to do what tar or a 10 line Python script could do. Not a realistic solution. -dr

On Wed, 2012-03-28 at 14:24 +0200, Emanuel Rumpf wrote: I am not particularly interested in reinventing the file system. I'm interested in a REALISTIC solution to the simple problem of session management. Anyway, these arguments only really make sense in at a hand-wavey level of abstraction. Let's jump back to reality and give these files a name. The user is going to delete, say, their grand piano sample bank, and need a special program to tell them that this means all that stuff they used that sample bank in will break? A user about to do so is actually going to check with this special program before deleting things? Every application is going to check with this special program before opening things that may be used destructively? (What applications even open things at random places on the file system destructively anyway). Users capable of using music production software are perfectly capable of loading files, and understanding that deleting things makes them go away. I've made some disparaging user jokes in my day, but good grief... All of this is ridiculously fragile anyway, and depends on every single file used by anything anywhere actually being imported in to the grand central file store. That is a fantasy, not a feasible reality. Users already have their organized collections of audio, samples, etc. and they aren't going to throw away their organization scheme and import them en-masse into this thing. I will stress again the point that ignoring implementation burden is guaranteed death of any such proposal. Facts: * Every file used by an audio program is not, and will never be, in a centralized location * Many programs have pre-defined state structures where files must be at particular paths. They can not and will not implement anything that breaks this and requires them to use a special interface for loading files * Any simple link-like mechanism is equivalent in power, so any such mechanism that isn't plain file-system links is imposing implementation burden across every layer of thick systems (including existing libraries), for little to no benefit If this makes sense, let's hear something that *can not work* without it. That might offset the MASSIVE implementation burden. Maybe. -dr

On Fri, 2012-03-30 at 16:47 +0200, Burkhard Wölfel wrote: [...] Good point. Better to achieve this kind of thing by simply dropping your (transparent file-based) session(s) in an RCS, which will do all of this a billion times better than any LAD session manager ever would. That said, I still think apps should be able to save non-destructively. "Use git" is a nice trick for geeks, not something that should ever be a strict dependency. -dr

On Wed, Mar 28, 2012 at 11:26:16AM +0200, Lieven Moors wrote: It is read-only to all the sessions in which it is used for mixdown into some format. It is evidently not read-only to the session that created that data. Not if you have a well defined workflow and know what you are doing, and I generally do. Because I know what I'm doing. If I edit the original recording for some reason (e.g. replacing a few measures by another take), then I expect the mixdown sessions to pick up the change if they are re-run. If I wouldn't want that I'd duplicate the data into each mixdown session instead. The 'dangerous' thing happens only because I want it. Having the option to do this doesn't affect any other user who doesn't want to do the same. 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)

On 03/26/2012 10:47 PM, rosea.grammostola wrote: I am able to save Ardour sessions and share it with my friends. They are able to use them (if Ardour and the right plugins are installed). How is this possible with NSM? \r

On 03/28/2012 10:43 PM, J. Liles wrote: Nice. I've to find another question or user scenario then, which will proof that NSM sucks anyway. People who can help me with this, don't hesitate to drop it on the list! Regards, \r

On 03/24/2012 11:09 PM, Fons Adriaensen wrote: How easy or how difficult is it compared to JackSession for example, to add NSM support to an application? Is it possible to have NSM and JackSession support in one application? Regards, \r

2012/3/29 Louigi Verona &lt;louigi.verona(a)gmail.com&gt; wasnt there a link somewhere in this mail thread about a comparison of all the pros and cons of 'all' SM's ? i went trough the thread but could not find it :-( ah well, maybe i'm just dreaming would be nice though, such a comparison matrix follow me on my Audio & Linux blog <http://audio-and-linux.blogspot.com/> !

2012/3/29 rosea.grammostola &lt;rosea.grammostola(a)gmail.com&gt; IMHO making such a matrix is the only good way to make a decisions of any kind is there anyone that has already made a 'study' that could be used as the basis of a comparison matrix ? thijs -- follow me on my Audio & Linux blog <http://audio-and-linux.blogspot.com/> !

2012/3/29 rosea.grammostola &lt;rosea.grammostola(a)gmail.com&gt; true, but currently we dont have any overview at all any tool is better than no tool, right ? follow me on my Audio & Linux blog <http://audio-and-linux.blogspot.com/> !

Am 29. März 2012 13:16 schrieb thijs van severen > I disagree here: Session managers have different concepts. A simple matrix doesn't do it (show it). IMHO user _experience_ is most important. 1. is it stable and reliable 2. does it do the job 3. behaves it practically (work-flow, feeling, user-interface) Thus it is best to simply try - a thing that is difficult, as long as an application is incomplete. Fortunately NSM and the other SMs have advanced enough to try. As I did mention, I have a good feeling with NSM and I'm trusting this thing to become complete. Thanks for your opinion. I tend to agree with you and Renato: rather not make it too complicated, but usable and reliable. -- E.R.

On 03/29/2012 12:02 PM, Louigi Verona wrote: Where are we talking about? The fact that the session manager manages the saving of the projects only? E.g. that's not possible to save a yoshimi 'project' from the GUI in Yoshimi when Yoshimi is in a session. (see below for details ***) It's a good thing to discuss indeed! The situation with a session is different I think. In your examples you use one application. In a Ardour session files are stored in the project folder normally. With a session you use more then one different applications, that's makes the stuff rather complex. I see an good point in making the situation less complex for and by the SM. Afaik you can do with your files what you want, by copying or moving from the NON Session folder. I also expect that an Ardour project saved in a NSM session, can also be opened by Ardour without being in a NSM session. Also I guess it will be still possible to export files (and import) from Ardour to anywhere you want, if Ardour would be in a NSM session. An example why this can be useful is the problems I had using JackSession with Hydrogen. Hydrogen didn't do the saving of the session folder and the hydrogen project right. This was probably avoided when they added NSM and followed the strict rules of it. That's how you see it, but the question is, is this true? Maybe we should let the developers speak for themselves. It would be good anyway that they speak out. It might be good if Jonathan Liles explains here why he has made the choice. \r *** 1.1.1. New This option may empty/reset the current file or project (possibly after user confirmation). UNDER NO CIRCUMSTANCES should it allow the user to create a new project/file in another location. 1.1.2. Open This option MUST be disabled. The application may, however, elect to implement an option called 'Import into Session', creates a copy of a file/project which is then saved at the session path provided by NSM. 1.1.3. Save This option should behave as normal, saving the current file/project as established by the NSM open message. UNDER NO CIRCUMSTANCES should this option present the user with a choice of where to save the file. 1.1.4. Save As This option MUST be disabled. The application may, however, elect to implement an option called 'Export from Session', which creates a copy of the current file/project which is then saved in a user-specified location outside of the session path provided by NSM. 1.1.5. Close (as distinguished from Quit or Exit) This option MUST be disabled unless its meaning is to disconnect the application from session management. 1.1.6. Quit or Exit This option may behave as normal (possibly asking the user to confirm exiting). http://non.tuxfamily.org/nsm/API.html

Am 29. März 2012 10:24 schrieb rosea.grammostola > NSM is not more difficult. Look at the yoshimi patch: Include a class, add some handlers, set some options, that's it. You have to know about OSC, but that's not hard. -- E.R.

On 03/22/2012 05:52 PM, Emanuel Rumpf wrote: I didn't have problems building it a few days ago. You probably could email the author or jump in on #lad