Re: [LAD] NSM - handling large files
Am 2. April 2012 20:05 schrieb Emanuel Rumpf xb...@web.de: NSM has some nice rules already, to make things behave smooth. Now add a few sensible rules, to make sure that audio-file management works equally well. These are really very simple points, I say. Proposing a few simple non-intrusive rules: - clients MUST create symlinks for all external files used - in the directory nsm/ sessions/ mysession/ myapp/ external-file-links/ - clients are ADVISED to store large-files in /nsm/ large-files/ (and create symlinks for them as in previous point) - all NSM-clients treat all files, as if they were inside their session-directory (means: they access all external files over the symlinks) - if a file must be external, apps create a symlink in their external-file-links/ folder and access the file through that link Without obtruding much on the application, nor on the SM (clients just create the symlinks and use them), this would - for the first version : - offer accaptable integrity. - ensure all files are either referenced-from or contained-in the session dir - ensure, if a file or link in the session-dir is modified or replaced, the new version is used by the nsm-client -- E.R. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] NSM - handling large files
- offer accaptable integrity. All further, extended functionality (export, import, copy, ...) could then become part of a script or of version 2.0 of NSM. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] NSM - handling large files
On 03.04.2012 06:49, Joel Roth wrote: On Thu, Mar 29, 2012 at 03:44:17PM +0200, Emanuel Rumpf wrote: Back to life - back to reality 1. We start qtractor as part of a session, create some midi-tracks, include some external wav-files. Should the SM know about these external files, as I suggested ? (Allowing the user to find out basic info about it. ) Or leave it completely to qtractor ? snip As I understand it, the primary motivation for a session manager is to be able to save and restore the state of an audio project[1] that consists of multiple interconnected programs running on a multiprocessing Linux system. In other words, the minimum capability sufficient to be useful would be some sort of checkpointing mechanism. A secondary goal, discussed extensively here, is that it would be nice to be able to copy a session or export a session. This is where all the contentious issues with handling filesystem objects comes up. The latter goal should be optional, IMO, rather than required. /snip this is exactly what i've been trying to tell (only that my english wording leaves a lot to be desired) thanks Joel :) the primary goal is already achieved by qtractor on jack-session and ladish; the second goal is the one i called utopian. speaking from a developer's pov. i find it very unlikely that NSM will ever get broader acceptance than jack-session and/or ladish, given the utopian restrictions it poses on client application design. i wonder for a while: modifying an application to participate in jack-session, for instance, is dead simple and costs only a small amount of developer time and effort, provided he/she has the proper motivation ;) otoh. i have this creepy feeling that, to comply to NSM, one has to compromise a lot of the application design and behavior--gui restrictions, file location restrictions, osc managing interface, to name a few--not that they are bad ideas at all, quite the contrary, but they impose a kind of non-negligible (pun intended;) change into application workings, unless coded to comply to the NSM-client-logo from day zero. i keep wondering: if that ever flies above its toes then i'll certainly call it The linux-audio revolution (or miracle, scnr:) cheers -- rncbc aka Rui Nuno Capela ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] NSM - handling large files
On Tue, 3 Apr 2012 07:04:55 + Emanuel Rumpf xb...@web.de wrote many things. Emanuel, why don't you write your own Session Manager (Protocol)? You seem to be very knowledgable. Nils ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] NSM - handling large files
On 04/03/2012 10:05 AM, rncbc wrote: On 03.04.2012 06:49, Joel Roth wrote: On Thu, Mar 29, 2012 at 03:44:17PM +0200, Emanuel Rumpf wrote: Back to life - back to reality 1. We start qtractor as part of a session, create some midi-tracks, include some external wav-files. Should the SM know about these external files, as I suggested ? (Allowing the user to find out basic info about it. ) Or leave it completely to qtractor ? snip As I understand it, the primary motivation for a session manager is to be able to save and restore the state of an audio project[1] that consists of multiple interconnected programs running on a multiprocessing Linux system. In other words, the minimum capability sufficient to be useful would be some sort of checkpointing mechanism. A secondary goal, discussed extensively here, is that it would be nice to be able to copy a session or export a session. This is where all the contentious issues with handling filesystem objects comes up. The latter goal should be optional, IMO, rather than required. /snip this is exactly what i've been trying to tell (only that my english wording leaves a lot to be desired) thanks Joel :) the primary goal is already achieved by qtractor on jack-session and ladish; the second goal is the one i called utopian. As far as I understood, to have everything saved in the session folder was designed to make the behavior of the session manager more predictable and more simple to avoid errors and misbehavior. To be able to export the session was *not* the primary choice for this (correct me if I am wrong). speaking from a developer's pov. i find it very unlikely that NSM will ever get broader acceptance than jack-session and/or ladish, given the utopian restrictions it poses on client application design. i wonder for a while: modifying an application to participate in jack-session, for instance, is dead simple and costs only a small amount of developer time and effort, provided he/she has the proper motivation ;) otoh. i have this creepy feeling that, to comply to NSM, one has to compromise a lot of the application design and behavior--gui restrictions, file location restrictions, osc managing interface, to name a few--not that they are bad ideas at all, quite the contrary, but they impose a kind of non-negligible (pun intended;) change into application workings, unless coded to comply to the NSM-client-logo from day zero. Feelings are important, especially when dealing with something like session management which success depends more or less by the adoption by others. But I think we need to know the *facts* here. Is it really that way as you think it is, or is it just your initial resistance (which one can understand) to comply to the strict rules of NSM and isn't it that bad when having a closer look at it? It's a reasonable point to discuss though... i keep wondering: if that ever flies above its toes then i'll certainly call it The linux-audio revolution (or miracle, scnr:) cheers -- rncbc aka Rui Nuno Capela ___ 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] NSM - handling large files
On 04/03/2012 11:38 AM, rosea.grammostola wrote: On 04/03/2012 10:05 AM, rncbc wrote: On 03.04.2012 06:49, Joel Roth wrote: On Thu, Mar 29, 2012 at 03:44:17PM +0200, Emanuel Rumpf wrote: Back to life - back to reality 1. We start qtractor as part of a session, create some midi-tracks, include some external wav-files. Should the SM know about these external files, as I suggested ? (Allowing the user to find out basic info about it. ) Or leave it completely to qtractor ? snip As I understand it, the primary motivation for a session manager is to be able to save and restore the state of an audio project[1] that consists of multiple interconnected programs running on a multiprocessing Linux system. In other words, the minimum capability sufficient to be useful would be some sort of checkpointing mechanism. A secondary goal, discussed extensively here, is that it would be nice to be able to copy a session or export a session. This is where all the contentious issues with handling filesystem objects comes up. The latter goal should be optional, IMO, rather than required. /snip this is exactly what i've been trying to tell (only that my english wording leaves a lot to be desired) thanks Joel :) the primary goal is already achieved by qtractor on jack-session and ladish; the second goal is the one i called utopian. As far as I understood, to have everything saved in the session folder was designed to make the behavior of the session manager more predictable and more simple to avoid errors and misbehavior. To be able to export the session was *not* the primary choice for this (correct me if I am wrong). * not the primary reason for this choice speaking from a developer's pov. i find it very unlikely that NSM will ever get broader acceptance than jack-session and/or ladish, given the utopian restrictions it poses on client application design. i wonder for a while: modifying an application to participate in jack-session, for instance, is dead simple and costs only a small amount of developer time and effort, provided he/she has the proper motivation ;) otoh. i have this creepy feeling that, to comply to NSM, one has to compromise a lot of the application design and behavior--gui restrictions, file location restrictions, osc managing interface, to name a few--not that they are bad ideas at all, quite the contrary, but they impose a kind of non-negligible (pun intended;) change into application workings, unless coded to comply to the NSM-client-logo from day zero. Feelings are important, especially when dealing with something like session management which success depends more or less by the adoption by others. But I think we need to know the *facts* here. Is it really that way as you think it is, or is it just your initial resistance (which one can understand) to comply to the strict rules of NSM and isn't it that bad when having a closer look at it? It's a reasonable point to discuss though... i keep wondering: if that ever flies above its toes then i'll certainly call it The linux-audio revolution (or miracle, scnr:) cheers -- rncbc aka Rui Nuno Capela ___ 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] NSM - handling large files
On 03.04.2012 10:38, rosea.grammostola wrote: On 04/03/2012 10:05 AM, rncbc wrote: On 03.04.2012 06:49, Joel Roth wrote: On Thu, Mar 29, 2012 at 03:44:17PM +0200, Emanuel Rumpf wrote: Back to life - back to reality 1. We start qtractor as part of a session, create some midi-tracks, include some external wav-files. Should the SM know about these external files, as I suggested ? (Allowing the user to find out basic info about it. ) Or leave it completely to qtractor ? snip As I understand it, the primary motivation for a session manager is to be able to save and restore the state of an audio project[1] that consists of multiple interconnected programs running on a multiprocessing Linux system. In other words, the minimum capability sufficient to be useful would be some sort of checkpointing mechanism. A secondary goal, discussed extensively here, is that it would be nice to be able to copy a session or export a session. This is where all the contentious issues with handling filesystem objects comes up. The latter goal should be optional, IMO, rather than required. /snip this is exactly what i've been trying to tell (only that my english wording leaves a lot to be desired) thanks Joel :) the primary goal is already achieved by qtractor on jack-session and ladish; the second goal is the one i called utopian. As far as I understood, to have everything saved in the session folder was designed to make the behavior of the session manager more predictable and more simple to avoid errors and misbehavior. To be able to export the session was *not* the primary choice for this (correct me if I am wrong). but is this one i complain about. nb. getting the full application state saved under one SM session directory is a lot different than saving everything an application state refers to under the same SM session directory. i'll gently recall you can actually have sort of both with qtractor under jack-session management: you just choose which of qtractor's default session file format you want: either the regular xml state file (.qtr) or the complete bundle, self-contained archive/zip file (.qtz). note that if your files are huge, saving in this latter format might just take more time :) however, please note, that's just a qtractor's user preference/convenience option, not mandated by any permanent rule of the SM API. byee -- rncbc aka Rui Nuno Capela ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] NSM - handling large files
On 04/03/2012 02:55 PM, rosea.grammostola wrote: On 04/03/2012 11:51 AM, rncbc wrote: On 03.04.2012 10:38, rosea.grammostola wrote: On 04/03/2012 10:05 AM, rncbc wrote: On 03.04.2012 06:49, Joel Roth wrote: On Thu, Mar 29, 2012 at 03:44:17PM +0200, Emanuel Rumpf wrote: Back to life - back to reality 1. We start qtractor as part of a session, create some midi-tracks, include some external wav-files. Should the SM know about these external files, as I suggested ? (Allowing the user to find out basic info about it. ) Or leave it completely to qtractor ? snip As I understand it, the primary motivation for a session manager is to be able to save and restore the state of an audio project[1] that consists of multiple interconnected programs running on a multiprocessing Linux system. In other words, the minimum capability sufficient to be useful would be some sort of checkpointing mechanism. A secondary goal, discussed extensively here, is that it would be nice to be able to copy a session or export a session. This is where all the contentious issues with handling filesystem objects comes up. The latter goal should be optional, IMO, rather than required. /snip this is exactly what i've been trying to tell (only that my english wording leaves a lot to be desired) thanks Joel :) the primary goal is already achieved by qtractor on jack-session and ladish; the second goal is the one i called utopian. As far as I understood, to have everything saved in the session folder was designed to make the behavior of the session manager more predictable and more simple to avoid errors and misbehavior. To be able to export the session was *not* the primary choice for this (correct me if I am wrong). but is this one i complain about. nb. getting the full application state saved under one SM session directory is a lot different than saving everything an application state refers to under the same SM session directory. i'll gently recall you can actually have sort of both with qtractor under jack-session management: you just choose which of qtractor's default session file format you want: either the regular xml state file (.qtr) or the complete bundle, self-contained archive/zip file (.qtz). note that if your files are huge, saving in this latter format might just take more time :) however, please note, that's just a qtractor's user preference/convenience option, not mandated by any permanent rule of the SM API. But Qtractor seems to be special case here. Jonathan said in this thread that there are not many apps with the same behavior when it comes to saving and using files/ sessions. So saying that this isn't ideal for Qtractor-like-applications, doesn't say that other developers have problems with the strict saving rules of NSM. (I have the *feeling* that these rules are in general harder to accept for developers of big applications like Qtractor, Ardour, Muse etc, then it is for small applications. The first have the unconscious urge of being in charge I can imagine, but I could be wrong). However, it might be fair to take a look at how JackSession does this and answer the question why it is or why it is not a problem to not have these saving restrictions. When searching for an answer, you find at least two quotes which tell you that it is important: [Quote=Fons] 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). [/Quote=Fons] *Why* this is essential isn't elaborated by Fons though. [quote=Liles] 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. [/quote=Liles] (Assuming that this ^ is because of the strict opening and saving rules of NSM). Liles compares here with LASH, undesirable hacks are not needed anymore. Why is this a primary requirement? Moreover LASH isn't seen as a serious candidate anyway these days. I would rather see a comparison with JackSession in this area. In other words: How JackSession does this and why is it, or why it is not, a problem to not have these strict rules for applications which are in a session. Regards, \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] NSM - handling large files
Am 3. April 2012 09:21 schrieb Nils l...@nilsgey.de: why don't you write your own Session Manager (Protocol)? You seem to be very knowledgable. I did not write a whole sequencer app yet, that's why I don't call that utopian ;) But Riu did. - I'm not able to do it better than NSM - we do not need 20 SMs, just one, that does it - NSM is here already, and is usable and is great There are many reasons to NOT write a SM, such as endless discussions on LAD about f..ng details I'm glad, some very brave devs nevertheless did. -- E.R. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] NSM - handling large files
Guys, is there any info on JACK Session state? What apps are supported? How to use? -- 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] NSM - handling large files
On 04/03/2012 04:18 PM, Louigi Verona wrote: Guys, is there any info on JACK Session state? What apps are supported? How to use? http://tangostudio.tuxfamily.org/en/documentations/jacksession ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] NSM - handling large files
On 04/03/2012 01:55 PM, rosea.grammostola wrote: On 04/03/2012 11:51 AM, rncbc wrote: On 03.04.2012 10:38, rosea.grammostola wrote: On 04/03/2012 10:05 AM, rncbc wrote: On 03.04.2012 06:49, Joel Roth wrote: On Thu, Mar 29, 2012 at 03:44:17PM +0200, Emanuel Rumpf wrote: Back to life - back to reality 1. We start qtractor as part of a session, create some midi-tracks, include some external wav-files. Should the SM know about these external files, as I suggested ? (Allowing the user to find out basic info about it. ) Or leave it completely to qtractor ? snip As I understand it, the primary motivation for a session manager is to be able to save and restore the state of an audio project[1] that consists of multiple interconnected programs running on a multiprocessing Linux system. In other words, the minimum capability sufficient to be useful would be some sort of checkpointing mechanism. A secondary goal, discussed extensively here, is that it would be nice to be able to copy a session or export a session. This is where all the contentious issues with handling filesystem objects comes up. The latter goal should be optional, IMO, rather than required. /snip this is exactly what i've been trying to tell (only that my english wording leaves a lot to be desired) thanks Joel :) the primary goal is already achieved by qtractor on jack-session and ladish; the second goal is the one i called utopian. As far as I understood, to have everything saved in the session folder was designed to make the behavior of the session manager more predictable and more simple to avoid errors and misbehavior. To be able to export the session was *not* the primary choice for this (correct me if I am wrong). but is this one i complain about. nb. getting the full application state saved under one SM session directory is a lot different than saving everything an application state refers to under the same SM session directory. i'll gently recall you can actually have sort of both with qtractor under jack-session management: you just choose which of qtractor's default session file format you want: either the regular xml state file (.qtr) or the complete bundle, self-contained archive/zip file (.qtz). note that if your files are huge, saving in this latter format might just take more time :) however, please note, that's just a qtractor's user preference/convenience option, not mandated by any permanent rule of the SM API. But Qtractor seems to be special case here. Jonathan said in this thread that there are not many apps with the same behavior when it comes to saving and using files/ sessions. So saying that this isn't ideal for Qtractor-like-applications, doesn't say that other developers have problems with the strict saving rules of NSM. (I have the *feeling* that these rules are in general harder to accept for developers of big applications like Qtractor, Ardour, Muse etc, then it is for small applications. The first have the unconscious urge of being in charge I can imagine, but I could be wrong). speaking of which ardour gets all its stuff under one own session directory, on a per session/project basis, iirc just like NSM mandates, bbbuut...:) making that one and the same directory as from an outsider/independent session manager like NSM is asking for a lot of file and symlink juggling, if you ask me i'm not an expert in ardour internals, someone else could chime in and help me here. my feeling again is that the effort to comply with NSM isn't, won't be so easy for any lass-than-simple-textbook-like client examples once again, i call for some ardour expertise. i'm even afraid to ask this btw, but does ardour work with jack-session already? o.O aham However, it might be fair to take a look at how JackSession does this and answer the question why it is or why it is not a problem to not have these saving restrictions. jack-session has some fsck-up restrictions of its own one that i had historical complaints is about this non-reusable session directory restriction (here, the non particle, is not a pun;) which meant that you can't save into the same session directory twice a really-smart/intelligent SM could copy and re(sym)link all the references under each client participant's session sub-directory, yes, a chimeric kind of effort comes to mind :o) alas. this jack-session restriction has been somewhat circumvented by the versioning feature on qjackctl-as-jack-session-manager, by yours truly. yes it's true, but it shows you how cumbersome is like when one has to go around and break the red tape of those draconian SM's ;) and now NSM is about asking for even more and thicker red tape... cough now, i could suggest NSM API to be split in levels of compliance and restrictiveness, so to speak: - level 0 :- clients just store/retrieve their own private state from a supplied and independent session sub-directory; no GUI File menu restrictions; no file location
Re: [LAD] NSM - handling large files
On Tue, Apr 3, 2012 at 6:35 AM, rosea.grammostola rosea.grammost...@gmail.com wrote: [quote=Liles] 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. [/quote=Liles] (Assuming that this ^ is because of the strict opening and saving rules of NSM). Liles compares here with LASH, undesirable hacks are not needed anymore. Why is this a primary requirement? Because LASH was designed with the assumption that all client applications would either: 1) Store all their state in memory and be fine with just dumping it to disk when the save yourself message came. 2) Naturally store their heavy state in some random place (like QTractor?) Programs with heavy state closely associated to the individual projects (like Non-DAW and Ardour) had to work around this by just storing the project data in some random place and only storing a reference to it in LASH, which was terrible from a consistency perspective because the user really had no idea where their data was. I want to have my sessions laid out on disk in a very specific way, with none of them named after GUIDs, and no applications/data being (mis)directed to a session just because it happened to be the last one active. With NSM (this is part of the server implementation and not the protocol) the user can lay things out on disk however they like, organizing their sessions in any way they want (including doing fancy things with subdirectories and symlinks) *and* have an expectation that e.g. the audio they record in Non-DAW after adding it as a client to a session *actually goes into the session directory they defined when they created the session*. If I want to back up my audio partition, I should not have to track down gigabytes of data from some hidden directory in $HOME that is only referred to inside incomprehensible XML files as well. The matter is complicated by applications which have been attempting to do their own crude form of session management. But here's the key point: It is only reasonable to expect an application to adhere to *one* system of session management at a time. So, if the application is connected to NSM, it should behave in a way consistent with other NSM capable applications, and if it is connected to XSM, JackSession or LASH, or what have you it can do whatever those systems allow (which is totally undefined anyway). Moreover LASH isn't seen as a serious candidate anyway these days. I would rather see a comparison with JackSession in this area. In other words: How JackSession does this and why is it, or why it is not, a problem to not have these strict rules for applications which are in a session. I believe JackSession was intended to be the bare minimum required to transmit a 'save' message to JACK applications... Just a very basic protocol. Doing anything more to ensure a smooth and consistent user experience is outside of its scope. A lot of this behavior depends on the implementation of the Session Manager server itself, but JackSession by its nature has some basic limitations that exclude the possibility of the kind of features NSM has, so a server implementation for it can only do so much... ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] NSM - handling large files
On Tue, Apr 3, 2012 at 10:04 AM, Rui Nuno Capela rn...@rncbc.org wrote: jack-session has some fsck-up restrictions of its own one that i had historical complaints is about this non-reusable session directory restriction (here, the non particle, is not a pun;) which meant that you can't save into the same session directory twice a really-smart/intelligent SM could copy and re(sym)link all the references under each client participant's session sub-directory, yes, a chimeric kind of effort comes to mind :o) alas. this jack-session restriction has been somewhat circumvented by the versioning feature on qjackctl-as-jack-session-**manager, by yours truly. yes it's true, but it shows you how cumbersome is like when one has to go around and break the red tape of those draconian SM's ;) and now NSM is about asking for even more and thicker red tape... cough now, i could suggest NSM API to be split in levels of compliance and restrictiveness, so to speak: - level 0 :- clients just store/retrieve their own private state from a supplied and independent session sub-directory; no GUI File menu restrictions; no file location restrictions, no symlinks, no juggling, no dupes, no sh*t. - level 1+ :- anything that (may progressively?) imposes each one the mentioned non-restrictions of level 0. starting with level 0, there's a fair chance for NSM to revolve, and even co-exist peacefully with jack-session and ladish. call me a dreamer :) Peacefully co-existing at the lowest common denominator of functionality completely defeats the purpose of trying to improve the integration experience for *users*. Remember, you only have to change the code once... People use this stuff every day. If there is a compliance level of 0, then developers will just pick that (you know it's true) and stop there. As far as the restrictions imposed by NSM... NSM requires very little of the application developer. The hardest part is if you want to support the session 'switch' functionality, and even that is not very difficult (hey, all the Non-* does it, so that means I had to implement it 4 times... so why are you complaining when you haven't even tried?) The requirement that you *not* do something is a hell of a lot easier to comply with than requiring that you do something complicated, which is exactly why NSM *doesn't* require applications to do anything complicated... ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] JACK CV Ports API
hey lads, sharing an idea I had here my (currently in development) host directly exposes plugin ports to jack - audio as audio, midi as midi, and parameters as a midi port for midi-cc usage. while coding for lv2 plugins, I noticed the CV port type, more info here: http://lv2plug.in/ns/ext/cv-port/ I didn't yet coded support for it, but I'll do soon. Those kind of ports will be exposed to jack as pure audio ports. Non-daw and non-mixer also use this kind of ports, and maybe others. The problem is that users shouldn't connect normal audio and CV ports together... so I came up with an idea that is simple and fairly easy to implement - a new jack port flag. example: port = jack_port_register(client, port_name, JACK_DEFAULT_AUDIO_TYPE, JackPortIsInput|JackPortIsCV, 0); patchbays can check for this flag and represent the port as a different type (I've done it here myself as jack keeps any custom port flag values I set, and works just fine). in the jack library code we can check for the flag and not allow port connections. what do you think? ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK CV Ports API
On Wed, 2012-04-04 at 00:24 +0100, Filipe Lopes wrote: hey lads, sharing an idea I had here my (currently in development) host directly exposes plugin ports to jack - audio as audio, midi as midi, and parameters as a midi port for midi-cc usage. while coding for lv2 plugins, I noticed the CV port type, more info here: http://lv2plug.in/ns/ext/cv-port/ I didn't yet coded support for it, but I'll do soon. Those kind of ports will be exposed to jack as pure audio ports. Non-daw and non-mixer also use this kind of ports, and maybe others. The problem is that users shouldn't connect normal audio and CV ports together... so I came up with an idea that is simple and fairly easy to implement - a new jack port flag. example: port = jack_port_register(client, port_name, JACK_DEFAULT_AUDIO_TYPE, JackPortIsInput|JackPortIsCV, 0); patchbays can check for this flag and represent the port as a different type (I've done it here myself as jack keeps any custom port flag values I set, and works just fine). in the jack library code we can check for the flag and not allow port connections. what do you think? ++ -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK CV Ports API
On Tue, Apr 3, 2012 at 4:24 PM, Filipe Lopes fal...@gmail.com wrote: hey lads, sharing an idea I had here my (currently in development) host directly exposes plugin ports to jack - audio as audio, midi as midi, and parameters as a midi port for midi-cc usage. while coding for lv2 plugins, I noticed the CV port type, more info here: http://lv2plug.in/ns/ext/cv-port/ I didn't yet coded support for it, but I'll do soon. Those kind of ports will be exposed to jack as pure audio ports. Non-daw and non-mixer also use this kind of ports, and maybe others. The problem is that users shouldn't connect normal audio and CV ports together... so I came up with an idea that is simple and fairly easy to implement - a new jack port flag. example: port = jack_port_register(client, port_name, JACK_DEFAULT_AUDIO_TYPE, JackPortIsInput|JackPortIsCV, 0); patchbays can check for this flag and represent the port as a different type (I've done it here myself as jack keeps any custom port flag values I set, and works just fine). in the jack library code we can check for the flag and not allow port connections. what do you think? BTW, SpiralSynthModular is another program that uses JACK audio ports for CV. Seems perfectly reasonable to me, although I would rather it be the connection manager that disallows the connections rather than JACK itself. Some users may have valid reasons for wanting to force a connection between Audio and CV ports (such as sending an analog control voltage signal out of the audio interface)... And consider the case right now for programs which have not been updated to set the appropriate flag on their CV ports--those connections would have to be forced until the programs are updated. But even if the connection manager just used the information to display the ports in a different color, it would still be useful. Also, obviously you need a #define or something to indicate that the version of libjack has the enum for CV ports. As you point out, it's a very simple change and I think it's about time we had *something* in place for this and in lieu of arbitrary port types and data representations, this will certainly work for the CV case. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
