Re: [LAD] NSM - handling large files
Guys, I read about JACK Session, tried it out. It does seem very capable. And if more apps add support (which, as people say in this discussion, is not that difficult), wouldn't JACK Session be a good, stable way to restore sessions? After all, JACK is a basic thing for Linux Audio and adding support for all its features, including Session, would just become part of the default routine. Am I missing something here? -- 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
Am 4. April 2012 08:11 schrieb Louigi Verona louigi.ver...@gmail.com: Am I missing something here? Yes, search the archives. or visit http://wiki.linuxaudio.org/wiki/user/emrum/jack_session_2_draft to see, what NSM tries to improve, by imposing some meaningful rules. ___ 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 07:04 PM, Rui Nuno Capela wrote: 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. How much more effort will it be in terms of coding, to implement 'level-1' versus 'level-0'? \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
On 04/04/2012 12:18 PM, rosea.grammostola wrote: On 04/03/2012 07:04 PM, Rui Nuno Capela wrote: 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. How much more effort will it be in terms of coding, to implement 'level-1' versus 'level-0'? speaking from qtractor pov.: - level 0: minimal effort as it would be a probable and simple rephrasing and/or adaptation of the code already in place for jack-session; also, there's this osc branch somewhat lurking in svn to get readily merged and apply for the NSM/OSC interface. - level 1+: pervasive change and effort; almost brand new application overhaul (iow. won't happen any time soon:) sorry. cheers -- rncbc aka Rui Nuno Capela rn...@rncbc.org ___ 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/04/2012 02:22 PM, Rui Nuno Capela wrote: On 04/04/2012 12:18 PM, rosea.grammostola wrote: On 04/03/2012 07:04 PM, Rui Nuno Capela wrote: 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. How much more effort will it be in terms of coding, to implement 'level-1' versus 'level-0'? speaking from qtractor pov.: - level 0: minimal effort as it would be a probable and simple rephrasing and/or adaptation of the code already in place for jack-session; also, there's this osc branch somewhat lurking in svn to get readily merged and apply for the NSM/OSC interface. - level 1+: pervasive change and effort; almost brand new application overhaul (iow. won't happen any time soon:) sorry. Another question. If you compare NSM level 0 (!) with JackSession. Which session manager do you prefer and why? 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 4. April 2012 11:18 schrieb rosea.grammostola rosea.grammost...@gmail.com: How much more effort will it be in terms of coding, to implement 'level-1' versus 'level-0'? For anyone who prefers to work with apps-do-whatever-they-want appraoch or we-have-zero-to-X-support-levels-so-you-dont-know-what-to-expect , there are alternatives: JackSession, Lash, Ladish. I would prefere at least *one* SM to have a clean and handy solution and hope that is NSM. I have to dig deeper into the NSM-API myself, but currently it's not obvious to me, why disabling a few menu-items and using symlinks in the session-dir. is recognized as impregnable obstacle. -- 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
On Wed, Apr 04, 2012 at 01:25:02PM +, Emanuel Rumpf wrote: For anyone who prefers to work with apps-do-whatever-they-want appraoch or we-have-zero-to-X-support-levels-so-you-dont-know-what-to-expect , there are alternatives: JackSession, Lash, Ladish. I would prefere at least *one* SM to have a clean and handy solution votes++ and hope that is NSM. I have to dig deeper into the NSM-API myself, but currently it's not obvious to me, why disabling a few menu-items and using symlinks in the session-dir. is recognized as impregnable obstacle. I fail to see that as well. And I may be an unrecoverable individualist, but if ever I add session management to any app then that app will obey the NSM rules or very similar ones if the session manager is not NSM - it is the obvious thing to do if you want something that works. 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] NSM - handling large files
On 04/04/2012 03:51 PM, Fons Adriaensen wrote: if ever I add session management to any app then that app will obey the NSM rules or very similar ones if the session manager is not NSM - it is the obvious thing to do if you want something that works. Could you elaborate your reasons for this, for those who don't see this as obvious? 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
On 04/04/2012 01:35 PM, rosea.grammostola wrote: On 04/04/2012 02:22 PM, Rui Nuno Capela wrote: On 04/04/2012 12:18 PM, rosea.grammostola wrote: On 04/03/2012 07:04 PM, Rui Nuno Capela wrote: 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. How much more effort will it be in terms of coding, to implement 'level-1' versus 'level-0'? speaking from qtractor pov.: - level 0: minimal effort as it would be a probable and simple rephrasing and/or adaptation of the code already in place for jack-session; also, there's this osc branch somewhat lurking in svn to get readily merged and apply for the NSM/OSC interface. - level 1+: pervasive change and effort; almost brand new application overhaul (iow. won't happen any time soon:) sorry. Another question. If you compare NSM level 0 (!) with JackSession. Which session manager do you prefer and why? well, NSM level 0 adds nothing to what JSM already delivers. sorry for the noise :) the once self-called uber-procrastinator says: prefer what is already there and de-facto working. of course it's a biased opinion nuff said :) -- rncbc aka Rui Nuno Capela rn...@rncbc.org ___ 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/04/2012 04:39 PM, Rui Nuno Capela wrote: Another question. If you compare NSM level 0 (!) with JackSession. Which session manager do you prefer and why? well, NSM level 0 adds nothing to what JSM already delivers. sorry for the noise :) the once self-called uber-procrastinator says: prefer what is already there and de-facto working. Your opinion is clear, but your arguments are not strictly correct I think. You say that a hypothetical NSM level 0, adds nothing to what JS delivers, but that's not true. When I want to save a session in JS, I have to make a new folder. If I want to save a slightly changed session, I have to make a new folder or choose a existent folder. If I do the latter, the gui ask me if I really want to overwrite it. I choose 'yes'. (This is what you could call pretty cumbersome). In one case, someone did choose the /home/user folder... and lost all his data. Ok, you've versioning now in qjackctl... There is no way in Qjackctl to add apps without JS support to the session. It is not possible to quit a session without saving it, so I have to close every application manually. In NSM on the other hand. I make a new session, add and remove apps on the fly from a nice centralized and quick GUI interface. It's even easy to add apps without NSM support (or scripts) via the GUI. If I change a session, I'm just able to save it without making a new folder or overwrite it. I am able to close a whole session and to abort a whole session (without saving). As a user can expect, all apps in the session close. Moreover it's possible to duplicate a session as a manner of using templates. It's very easy and fast to change between sessions. I am able to use session over the network very easily. I have never the risk of overwriting my precious data. I' m able to add applications without JACK support to NSM (Frescobaldi notation-editor, Emacs with SuperCollder etc.). If you say that NSM adds nothing then a) you didn't try it and don't really know where you're talking about or b) don't think that the NSM stuff mentioned above are valuable of any kind for a user. Regards, \r If ___ 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/04/2012 04:55 PM, rosea.grammostola wrote: On 04/04/2012 04:39 PM, Rui Nuno Capela wrote: Another question. If you compare NSM level 0 (!) with JackSession. Which session manager do you prefer and why? well, NSM level 0 adds nothing to what JSM already delivers. sorry for the noise :) the once self-called uber-procrastinator says: prefer what is already there and de-facto working. Your opinion is clear, but your arguments are not strictly correct I think. You say that a hypothetical NSM level 0, adds nothing to what JS delivers, but that's not true. When I want to save a session in JS, I have to make a new folder. If I want to save a slightly changed session, I have to make a new folder or choose a existent folder. If I do the latter, the gui ask me if I really want to overwrite it. I choose 'yes'. (This is what you could call pretty cumbersome). I'm not sure if this is cumbersomeness of Qjackctl as a GUI for JackSession or JackSession itself. I'm not sure how this works in Pyjacksm (which is a pretty limited GUI and not in active development). In one case, someone did choose the /home/user folder... and lost all his data. Ok, you've versioning now in qjackctl... There is no way in Qjackctl to add apps without JS support to the session. It is not possible to quit a session without saving it, so I have to close every application manually. In NSM on the other hand. I make a new session, add and remove apps on the fly from a nice centralized and quick GUI interface. It's even easy to add apps without NSM support (or scripts) via the GUI. Btw this should in theory also be possible with JS I think. Someone could write a GUI possibly that is also capable of starting applications from it. Moreover JS can make use of infra clients, (an alpha version of) pyjacksm supports this via a configuration file, .pyjacksmrc Which looks like this, for example: [DEFAULT] sessiondir = ~/linuxaudio/JacksmpySession [infra] a2j = a2jmidid -e jkmeter = jkmeter Then it should be possible to add applications without JS support or without a 'state to save' to the JackSession. BUT, this is *not* implemented in Qjackctl. Pyjacksm sessions are *not* exchangeable with qjackctl http://tangostudio.tuxfamily.org/en/documentations/jacksession If I change a session, I'm just able to save it without making a new folder or overwrite it. I am able to close a whole session and to abort a whole session (without saving). As a user can expect, all apps in the session close. Moreover it's possible to duplicate a session as a manner of using templates. It's very easy and fast to change between sessions. I am able to use session over the network very easily. I have never the risk of overwriting my precious data. I' m able to add applications without JACK support to NSM (Frescobaldi notation-editor, Emacs with SuperCollder etc.). If you say that NSM adds nothing then a) you didn't try it and don't really know where you're talking about or b) don't think that the NSM stuff mentioned above are valuable of any kind for a user. Regards, \r If ___ 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/04/2012 03:55 PM, rosea.grammostola wrote: On 04/04/2012 04:39 PM, Rui Nuno Capela wrote: Another question. If you compare NSM level 0 (!) with JackSession. Which session manager do you prefer and why? well, NSM level 0 adds nothing to what JSM already delivers. sorry for the noise :) the once self-called uber-procrastinator says: prefer what is already there and de-facto working. Your opinion is clear, but your arguments are not strictly correct I think. You say that a hypothetical NSM level 0, adds nothing to what JS delivers, but that's not true. When I want to save a session in JS, I have to make a new folder. If I want to save a slightly changed session, I have to make a new folder or choose a existent folder. If I do the latter, the gui ask me if I really want to overwrite it. I choose 'yes'. (This is what you could call pretty cumbersome). In one case, someone did choose the /home/user folder... and lost all his data. Ok, you've versioning now in qjackctl... There is no way in Qjackctl to add apps without JS support to the session. It is not possible to quit a session without saving it, so I have to close every application manually. In NSM on the other hand. I make a new session, add and remove apps on the fly from a nice centralized and quick GUI interface. It's even easy to add apps without NSM support (or scripts) via the GUI. If I change a session, I'm just able to save it without making a new folder or overwrite it. I am able to close a whole session and to abort a whole session (without saving). As a user can expect, all apps in the session close. Moreover it's possible to duplicate a session as a manner of using templates. It's very easy and fast to change between sessions. I am able to use session over the network very easily. I have never the risk of overwriting my precious data. I' m able to add applications without JACK support to NSM (Frescobaldi notation-editor, Emacs with SuperCollder etc.). If you say that NSM adds nothing then a) you didn't try it and don't really know where you're talking about or b) don't think that the NSM stuff mentioned above are valuable of any kind for a user. i may have missed it, but those application clients which are NOT coded as compliant to a session protocol are not the point--that's just a SM implementation convenience outside of the bounds of the ideal-SM discussion i'll refresh your memory that pyjacksm (a JSM reference implementation) does that too (something called exo-clients or wtf:). ladish have been doing that also and way, way before, for ages now o.O unfortunately, i reckon, qjackctl doesn't. on my own call it has been purestrict to the JS business (aka. protocol) and nothing more. however, re. exo-/infra-clients (or w/e they've been called, i don't quite remember exactly but those are about clients which are non-jack-session-aware) are in the drawer ntl. actually, i was minding about the *intrinsic* cost/benefits of the session protocol and *not* about *any* particular *session management* (SM) implementation got that? -- rncbc aka Rui Nuno Capela rn...@rncbc.org ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] What 16chan sound card
Hi guys, I want to buy a usb sound card with the following specs: 16 input channels : at least 8 Mic ins, the rest line ins, intrument ins or ADAT ins (optical) no spdif output channels: 8 would be nice but not a must price: 300-350 € I have these on my list: http://www.thomann.de/de/256918tascam_us1800.htm (has no ADAT, but only spdif) http://www.thomann.de/de/phonic_firefly_808_retour.htm (unkown manufacturer, at least to me) Can someone tell how good these do with jack/linux,or maybe show another option. Thanx, Gerald ___ 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 Wed, Apr 4, 2012 at 5:22 AM, Rui Nuno Capela rn...@rncbc.org wrote: On 04/04/2012 12:18 PM, rosea.grammostola wrote: On 04/03/2012 07:04 PM, Rui Nuno Capela wrote: 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. How much more effort will it be in terms of coding, to implement 'level-1' versus 'level-0'? speaking from qtractor pov.: - level 0: minimal effort as it would be a probable and simple rephrasing and/or adaptation of the code already in place for jack-session; also, there's this osc branch somewhat lurking in svn to get readily merged and apply for the NSM/OSC interface. - level 1+: pervasive change and effort; almost brand new application overhaul (iow. won't happen any time soon:) sorry. Are you seriously saying that the equivalent of doing: if ( nsm_is_active ) save_here( file ); else save_there( file ); Would require a complete rewrite and overhaul of your application? Say you don't want to do it... That's fine. Say you don't like the NSM design--that's fine too. But don't just make up wild hyperbole out of laziness... ___ 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/04/2012 05:46 PM, Rui Nuno Capela wrote: On 04/04/2012 03:55 PM, rosea.grammostola wrote: On 04/04/2012 04:39 PM, Rui Nuno Capela wrote: Another question. If you compare NSM level 0 (!) with JackSession. Which session manager do you prefer and why? well, NSM level 0 adds nothing to what JSM already delivers. sorry for the noise :) the once self-called uber-procrastinator says: prefer what is already there and de-facto working. Your opinion is clear, but your arguments are not strictly correct I think. You say that a hypothetical NSM level 0, adds nothing to what JS delivers, but that's not true. When I want to save a session in JS, I have to make a new folder. If I want to save a slightly changed session, I have to make a new folder or choose a existent folder. If I do the latter, the gui ask me if I really want to overwrite it. I choose 'yes'. (This is what you could call pretty cumbersome). In one case, someone did choose the /home/user folder... and lost all his data. Ok, you've versioning now in qjackctl... There is no way in Qjackctl to add apps without JS support to the session. It is not possible to quit a session without saving it, so I have to close every application manually. In NSM on the other hand. I make a new session, add and remove apps on the fly from a nice centralized and quick GUI interface. It's even easy to add apps without NSM support (or scripts) via the GUI. If I change a session, I'm just able to save it without making a new folder or overwrite it. I am able to close a whole session and to abort a whole session (without saving). As a user can expect, all apps in the session close. Moreover it's possible to duplicate a session as a manner of using templates. It's very easy and fast to change between sessions. I am able to use session over the network very easily. I have never the risk of overwriting my precious data. I' m able to add applications without JACK support to NSM (Frescobaldi notation-editor, Emacs with SuperCollder etc.). If you say that NSM adds nothing then a) you didn't try it and don't really know where you're talking about or b) don't think that the NSM stuff mentioned above are valuable of any kind for a user. i may have missed it, but those application clients which are NOT coded as compliant to a session protocol are not the point--that's just a SM implementation convenience outside of the bounds of the ideal-SM discussion i'll refresh your memory that pyjacksm (a JSM reference implementation) does that too (something called exo-clients or wtf:). ladish have been doing that also and way, way before, for ages now o.O unfortunately, i reckon, qjackctl doesn't. on my own call it has been purestrict to the JS business (aka. protocol) and nothing more. That's probably the most essential part on LAD to discuss indeed, the session protocol. But that doesn't take away that for a user these are essential components. The user is looking at how an (SM) application is presented on his Desktop, the *end-product*. And because of the fact that also the LAU'er knows that it is 'utopian' to think that all the apps on apps.linuxaudio.org will get session support, it *is* a important matter a SM has to deal with. If Qjackctl doesn't offer this functionality by purpose, it is a obvious disadvantage for the user at the end. however, re. exo-/infra-clients (or w/e they've been called, i don't quite remember exactly but those are about clients which are non-jack-session-aware) are in the drawer ntl. actually, i was minding about the *intrinsic* cost/benefits of the session protocol and *not* about *any* particular *session management* (SM) implementation True, we've to make clear what the technical possibilities of a SM are. You're saying that a hypothetical NSM level-0 offers nothing more compared to JackSession in this scope. I do also doubt this, you might be able to tell me what JackSession can do from the things I described as advantages of NSM. I can think of these at least, which still stand: - JackSession is not able to quit the applications in the session without saving. - It is not possible to add applications without JACK support to a JackSession (Frescobalid, Emacs with SuperCollider) - Changing between NSM sessions is more easy and faster - with NSM you can use the duplicate function and so use templates - with NSM you can open multiple session on one host - NSM has a clear way how to use a session on multiple computers via the network - NSM sessions are not machine dependent (level 1) This is just a quick brainstorm. As mentioned, this doesn't talk about the end implementation benefits of NSM for the user, which are of equal importance for the end-user. On that topic I conclude that Qjackctl doesn't support infra clients by purpose and that I don't see it happen that there will be another GUI who does support in the near future. Regards, \r ___ Linux-audio-dev
Re: [LAD] NSM - handling large files
On Wed, Apr 04, 2012 at 04:37:59PM +0200, rosea.grammostola wrote: Could you elaborate your reasons for this, for those who don't see this as obvious? I could. But it wouldn't help anyone. 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] NSM - handling large files
On 04/04/2012 05:19 PM, J. Liles wrote: On Wed, Apr 4, 2012 at 5:22 AM, Rui Nuno Capela rn...@rncbc.org mailto:rn...@rncbc.org wrote: On 04/04/2012 12:18 PM, rosea.grammostola wrote: On 04/03/2012 07:04 PM, Rui Nuno Capela wrote: 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. How much more effort will it be in terms of coding, to implement 'level-1' versus 'level-0'? speaking from qtractor pov.: - level 0: minimal effort as it would be a probable and simple rephrasing and/or adaptation of the code already in place for jack-session; also, there's this osc branch somewhat lurking in svn to get readily merged and apply for the NSM/OSC interface. - level 1+: pervasive change and effort; almost brand new application overhaul (iow. won't happen any time soon:) sorry. Are you seriously saying that the equivalent of doing: if ( nsm_is_active ) save_here( file ); else save_there( file ); this is level 0, assuming file is the application private state file Would require a complete rewrite and overhaul of your application? Say you don't want to do it... That's fine. Say you don't like the NSM design--that's fine too. But don't just make up wild hyperbole out of laziness... the rewrite is about level 1+ (my nomenclature, i know:) cheers -- rncbc aka Rui Nuno Capela rn...@rncbc.org ___ 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/04/2012 05:19 PM, rosea.grammostola wrote: ... On that topic I conclude that Qjackctl doesn't support infra clients by purpose and that I don't see it happen that there will be another GUI who does support in the near future. wait, it's not by purpose but just overlooked ok? infra-clients (ie. jack clients unaware of jack-session) and exo-clients (non-jack applications) are here subjects of a covenant: the SM in charge, by its particular implementation, follows some god-knows-what convention which is NOT bounded by the session protocol (or API) at all--of course, the suspects are not session-aware to begin with, so any SM can raise its own convention and make up its own party--it's a free world isn't it? :) as said, infra/exo-clients support on qjackctl (as a JSM) is in the drawer, meaning it's coming out any day soon. so, is there yet another convention party in the making, you ask? yep:) cheers -- rncbc aka Rui Nuno Capela rn...@rncbc.org ___ 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/04/2012 08:51 PM, Rui Nuno Capela wrote: On 04/04/2012 05:19 PM, rosea.grammostola wrote: ... On that topic I conclude that Qjackctl doesn't support infra clients by purpose and that I don't see it happen that there will be another GUI who does support in the near future. wait, it's not by purpose but just overlooked ok? infra-clients (ie. jack clients unaware of jack-session) and exo-clients (non-jack applications) are here subjects of a covenant: the SM in charge, by its particular implementation, follows some god-knows-what convention which is NOT bounded by the session protocol (or API) at all--of course, the suspects are not session-aware to begin with, so any SM can raise its own convention and make up its own party--it's a free world isn't it? :) as said, infra/exo-clients support on qjackctl (as a JSM) is in the drawer, meaning it's coming out any day soon. so, is there yet another convention party in the making, you ask? That would take away one, for me important, advantage of NSM compared to JackSession atm (for the user). All though the implementation in Pyjacksm, is more cumbersome (using configuration file where you have to set each application you use) compared to NSM (no thinking, just adding clients). One might ask why this isn't already in Qjackctl and how long it will take though. Which brings me to another possible advantage of NSM. The fact that the developer is clearly dedicated to the ask in time and motivation. And also important, he uses NSM himself and believes in session management. (I little reasons to believe that JS devs use JackSession themselves. Also if I read your words well Rui, I don't think you use Qjackctls session option yourself). With JackSession you lack those things atm (no blaming here). It's probably no accident that in NSM it's all there, whereas for JackSession some features still have to be implemented (in the GUI). Personally I asked for the infra client feature way back, but it's still not there. A new project like NSM seems to be needed to get some new progress, this is not the kind of dedication such a project needs (no blaming). But of course, this are not the only reason to prefer one SM above the other. As mentioned in my previous mails, there are arguments for me atm to say that NSM gives a user more then JackSession (even with the hypothetical level-0). NSM seems to be a SM which has a very good and simple solution, more functionality then JackSession, without the need of things like Jackdbus (ladish). Also I've the opinion that the community should go with the best implementation. Why go for an implementation which lacks useful functionality when implementation into the apps are more or less the same effort? I think it's essential to the discussion to get the cards on the table, so everybody can make up his own mind and decides which SM is the best solution for the Linuxaudio session puzzle. It would be nice if we could reach agreement on this, but it's a free world indeed. :) 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
On 04/04/2012 09:59 PM, rosea.grammostola wrote: But of course, this are not the only reason to prefer one SM above the other. As mentioned in my previous mails, there are arguments for me atm to say that NSM gives a user more then JackSession (even with the hypothetical level-0). NSM seems to be a SM which has a very good and simple solution, more functionality then JackSession, without the need of things like Jackdbus (ladish). Also I've the opinion that the community should go with the best implementation. Why go for an implementation which lacks useful functionality when implementation into the apps are more or less the same effort? Afaik, NSM gives us all we users need when it comes to LAU session management. You've to help me to give something it doesn't do in this scope. If you can't help me with this, you can more or less take the conclusion that NSM is a final solution to the Linuxaudio session puzzle. Final as in, does all what it should do, has intrinsic all the stuff it should be able to do in the coming 10 yrs, it doesn't lack essential features in terms of functionality and workflow, if a better SM bumps up in the coming yrs there will likely be no essential reasons to switch to that one (which makes the effort for adding NSM support to an app, a valuable and longstanding contribution). Correct me if I'm wrong. 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
On Wed, Apr 04, 2012 at 09:19:57AM -0700, J. Liles wrote: Are you seriously saying that the equivalent of doing: if ( nsm_is_active ) save_here( file ); else save_there( file ); Would require a complete rewrite and overhaul of your application? Say you don't want to do it... That's fine. Say you don't like the NSM design--that's fine too. But don't just make up wild hyperbole out of laziness... :-) A question: according to the docs, a client should consider itself 'managed' after receiving the reply to the 'announce' message. But at that time it has no path to save anything 'New' or 'Load'ed. If I understand the docs correctly, the 'open' message specifying this path will follow immediately. But still this is a possible race condition. So shouldn't a client consider itself managed only after having received the first 'open' message ? 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] NSM - handling large files
On Wed, 2012-04-04 at 21:59 +0200, rosea.grammostola wrote: [...] I think it's essential to the discussion to get the cards on the table, so everybody can make up his own mind and decides which SM is the best solution for the Linuxaudio session puzzle. It would be nice if we could reach agreement on this, but it's a free world indeed. :) With apologies in advance, here are my cards: It would be nice if this list could stick to actual developer/development problems. I just spent quite some time catching up on this thread, and almost nothing at all of value (i.e. something towards solving the/a problem) has been contributed since last I checked. Mostly just a bunch of wannabe bureaucracy political noise, which only obscures any actual technical points that might need fleshing out (i.e. it's actively hurting, not helping). I doubt I'm the only one interested in the problem who's just given up on this thread because the signal:noise ratio is ridiculous. Take the politics to LAU or something. The official resolution of the User Committee on The Agreed-Upon Solution for LAD Session Management will have zero impact on what developers actually implement, but dragging the signal:noise ratio into the gutter might - though probably not the impact you were hoping for. -dr ___ 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 Wed, Apr 4, 2012 at 1:48 PM, Fons Adriaensen f...@linuxaudio.org wrote: On Wed, Apr 04, 2012 at 09:19:57AM -0700, J. Liles wrote: Are you seriously saying that the equivalent of doing: if ( nsm_is_active ) save_here( file ); else save_there( file ); Would require a complete rewrite and overhaul of your application? Say you don't want to do it... That's fine. Say you don't like the NSM design--that's fine too. But don't just make up wild hyperbole out of laziness... :-) A question: according to the docs, a client should consider itself 'managed' after receiving the reply to the 'announce' message. But at that time it has no path to save anything 'New' or 'Load'ed. If I understand the docs correctly, the 'open' message specifying this path will follow immediately. But still this is a possible race condition. So shouldn't a client consider itself managed only after having received the first 'open' message ? Yes. Well, there's a bit of a fine distinction between being managed and being part of the session. The application could conceivably receive a 'quit' message before the 'open' message, but that would never actually happen in the current implementation and doesn't make a lot of sense anyway. I think you're probably right in that for all practical purposes 'open' is the time to consider the application managed. ___ 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 Wed, Apr 4, 2012 at 3:22 PM, J. Liles malnour...@gmail.com wrote: On Wed, Apr 4, 2012 at 1:48 PM, Fons Adriaensen f...@linuxaudio.orgwrote: On Wed, Apr 04, 2012 at 09:19:57AM -0700, J. Liles wrote: Are you seriously saying that the equivalent of doing: if ( nsm_is_active ) save_here( file ); else save_there( file ); Would require a complete rewrite and overhaul of your application? Say you don't want to do it... That's fine. Say you don't like the NSM design--that's fine too. But don't just make up wild hyperbole out of laziness... :-) A question: according to the docs, a client should consider itself 'managed' after receiving the reply to the 'announce' message. But at that time it has no path to save anything 'New' or 'Load'ed. If I understand the docs correctly, the 'open' message specifying this path will follow immediately. But still this is a possible race condition. So shouldn't a client consider itself managed only after having received the first 'open' message ? Yes. Well, there's a bit of a fine distinction between being managed and being part of the session. The application could conceivably receive a 'quit' message before the 'open' message, but that would never actually happen in the current implementation and doesn't make a lot of sense anyway. I think you're probably right in that for all practical purposes 'open' is the time to consider the application managed. Also, to clairify, by 'quit' I mean SIGTERM and furthermore, there's no reason that the announce reply and the first open message can't be in an OSC 'bundle' to guarantee they are processed at the same time (although the current implementation doesn't use bundles). ___ 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/04/2012 11:22 PM, David Robillard wrote: On Wed, 2012-04-04 at 21:59 +0200, rosea.grammostola wrote: [...] I think it's essential to the discussion to get the cards on the table, so everybody can make up his own mind and decides which SM is the best solution for the Linuxaudio session puzzle. It would be nice if we could reach agreement on this, but it's a free world indeed. :) With apologies in advance, here are my cards: Thanks, with my apologies in advance for my reply. :) It would be nice if this list could stick to actual developer/development problems. Of course this is the LAD list, so I don't post often on this list, except for this topic, started by me and of importance for me. I think this topic is a special case on LAD, because it's by far more interesting for users to have a good SM implementation then for developers. For musicians/ user it is a real problem when something doesn't work or when a session API is implemented badly (technically and/ or socially). Developers care much less. But if you make such a strict border between devs and users, also in such a topic, as you seem to suggest, I'm afraid we'll have to deal with the same 'great-technical-design' but 'sorry-not-yet-usable-if-you-really-want-to-make-music' software issues in the coming years on Linux. Or in the case of session management,'great-minimal-design' but 'useless-because-you-can-only-use-a-few-apps-and-we-dont-have-a-problem-with-that-because-we-dont-use-it-ourselves'. I'll tell you why this topic is important to me. I did a talk about Linuxaudio. I can't tell you how much of a pain it was to get my stuff together. It did cost me more then a *fulltime week, 10h a day* to be able to show a more or less workable Linuxaudio workflow. Truly ridiculous and it made me realize that JackSession is utopian (and probably making music on Linux too) in this state. It's nice to talk about software design side of Linuxaudio, but actually working with it is a whole different story, I tell you...especially the combination 'making music' and 'the modular approach'... (NSM seems to change this quite a bit though) But if you're only interested in technical stuff and academic discussion about APIs, this might be not very interesting to read for you, my apologies. up on this thread, and almost nothing at all of value (i.e. something towards solving the/a problem) has been contributed since last I checked. Mostly just a bunch of wannabe bureaucracy political noise, which only obscures any actual technical points that might need fleshing out (i.e. it's actively hurting, not helping). Take the politics to LAU or something. Call it politics, or call it just an obvious part of the process of implementing something like a session manager API, where a large part of the community has to deal with. For me it's not politics in the sense that I like to see API X supported, rather then API Y, don't get me wrong. I just think it's important to get the real true (technical/ LAD related) arguments on table, it helps already to get the picture clear and to kill argumentation flaws, wrong suggestions and myths. That's in the benefit for devs and users. 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
On Tue, 2012-04-03 at 18:04 +0100, Rui Nuno Capela wrote: [...] 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. I don't know what you are trying to say. One and the same directory as from an outsider/independent session manager? Huh? A directory of files is a directory of files. The format Ardour would save to inside of a session is precisely the same format it already saves in, perhaps with some things being links. I can guarantee you that much, because if it had to be different, Ardour, like presumably most apps, simply would never implement it... 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 Not really. Qtractor is just a weirdo edge case. You seem to be trying to paint the mandates of NSM as deeply imposing requirements, but they're not. Quite the opposite, really, anything else would certainly be *far* more imposing and complicated. That's kind of the point. It's not really worth it to care about this case from an SM perspective since it's rare, easily fixable, inherently un-archivable, and there's no palatable solution for dealing with apps like this anyway. The obvious one would be to have a special 'deep save', but then... if the app implements that, it can just save that way when running in an SM every time. Therefore it's a non-issue (heh) for SM. -dr ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
