Re: [LAD] new-session-management on jackaudio.org
‐‐‐ Original Message ‐‐‐ On Monday, April 5, 2021 11:25 AM, Fons Adriaensen wrote: > On Sun, Apr 04, 2021 at 10:37:25PM +0000, rosea.grammostola wrote: > > > Somehow they need backup to get some authority apparently. > > Gotohttps://jackaudio.org and look around. Do you see NewSM there ? > It's not even in the applications list (it probably should be). > > Also please try to understand the difference between > > 1. https://new-session-manager.jackaudio.org and > 2. https://jackaudio.org/new-session-manager. > > or for that matter > > 3. http://kokkinizita.linuxaudio.org and > 4. http://linuxaudio.org/kokkinizita > > and note that what we have is (1) in both cases, and (2) does > not exist. > > That means e.g. that https://new-session-manager.jackaudio.org > not a part of the https://jackaudio.org site as it would be > for (2). They just share a host. > > > > We're the official NSM. > > There is nothing onhttps://new-session-manager.jackaudio.org/ that > says so. There is this: > > 'The goal is to become the de-facto standard music session manager > for Linux distributions.' > > IMHO there's nothing wrong with that. Every author would be very happy > to see his/her brain child become the de-facto standard. That's exactly one of the problems. It's not their brainchild. NSM is the brainchild of the developer of Non-Session-Manager (NSM). newSM as you call it, is a copy of it. That's why I raised the question, which version should be on jackaudio.org? The original or the fork? Fork A or fork B? This leads to the next problematic situation, that the JACK maintainer is also the initiator and maintainer of the NSM fork. Guess which version he chooses now and in the future. There is a conflict of interest here... again... unfortunately. I've two points against the fork, a ethical and a technical. I don't like how the brainchild of the original author is totally hijacked by some people, hijacking linuxaudio.org for it in the same time to make this possible. Fons, I don't think I've to quote your responses to the way they forked and the names they gave it. You used even stronger words then I did, which says something. The end-result is that the Non author removed his source code (temporarily?) from the web in anger and despair. It's also harsh that the original author had very good technical arguments to reject solutions to problems, which he thought they where the wrong analyses of the problems or the wrong solutions. He gave several options to implement solutions in a different way, which where in line with the ideas behind NSM instead. I agreed with him most of the time. Harsh if the above points means that the fork gets a place on jackaudio.org, while the ethics of how this fork has been forked are far off and the technical implementations disputable. These questionable ethics and disputable technical solutions would be much more arbitrary and not part of the discussion here if they would just stick with the NSM api (which they do, if I've to believe it, but that's questionable as well) and if they would put their fork on a own website. Using linuxaudio.org or now jackaudio.org makes these matters far more problematic. Then it becomes a community issue and then there then it's more a matter of, who has the most power or the best connections in the community. The situation with regards linuxaudio.org was more principal for me. I feel I've less to say about jackaudio.org, but here is my take on it: Keep the NSM fork separated from jackaudio.org, (especially until all the ethical issues are solved). Avoid conflict of interest between the JACK maintainer and his NSM fork. Don't 'pollute' the JACK project with the ethics and discussion about the NSM fork. Don't make the JACK project (indirectly) responsible for it, in any way. Put the NSM fork on it's own website or on the website of it's authors, kx.studio or laborejo.org. Give a short explanation on the jackaudio.org website about session management, e.g. NSM and link to the original API and if you like to the forks API (but they where the same...) if you like. Throwing another $0.02 in the box. Not much cents left... ;) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] new-session-management on jackaudio.org
> > NSM's strict rules for client behaviour are what ensures that it will > be able to perform as promised. Something similar was missing in all > other Linux session manager systems I know of. So I'm very happy to > see Jack-session deprecated. > > Just my 2e-2 Euro of course. I think this is not about jack-session vs NSM. The last implementation of jack-session support in a application must have been years ago. Nobody knows what jack-session is and nobody is actively busy with it. A short explanation and a link to the NSM API on jackaudio.org would do. Note also that NSM is explicitly designed without a dependency to JACK. I'm happy about the removal of the connections with linuxaudio.org, but I don't understand why they now link up with jackaudio.org. The fork is highly debated and currently, points of criticism and requests from the original author and others are still not fully honored, like the naming, the use of NSM abbreviation and such. I wouldn't want that discussion being moved to jackaudio.org, also not if I stood in their shoes. It's just not smart. Somehow they need backup to get some authority apparently. We're the official NSM. One wonders why is the original NSM not hosted on jackaudio.org, or raysession or the next better session thing. Who is deciding this? I'm much more a proponent of such projects being independent, certainly knowing the history of and discussion around this fork. Make sure your software is good enough to get noticed and used. Take full responsibility for it yourself. Give it a nice dedicated website. People will find it (and developers will find it via a weblink on jackaudio.org). My 0.02 guilders. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] NSM fork
‐‐‐ Original Message ‐‐‐ On Friday, January 29, 2021 11:44 PM, Fons Adriaensen wrote: > On Fri, Jan 29, 2021 at 07:59:58PM +, John Rigg wrote: > > > I don't think the fork was handled very well, with antagonism > > on both sides which could easily have been avoided with a > > little forethought. > > Indeed. > > > The choice of the name New Session Manager and the re-use of > > the NSM initials is an obvious problem IMO. > > I agree. Also presenting this as a consortium project is > questionable to put it mildly. I'm glad that I'm not the only one. I think there are two aspects, one ethical and one practical. The way they try to take over the NSM landscape, with their deceiving use of language and the (mis)use of their community roles, doesn't show any signs of respect to the one who actually designed this thing. Nor to it's community who worked hard to create this unique linuxaudio session management landscape. Not being humble, because you realize you just copied the thing, but didn't design it. Then there is the practical side, where it is obvious that it's not good that two teams work on the same session management landscape and on the same API, cause they took the freedom to change the API without discourse too. Personally I did my best to avoid it. I thought I was working with the Agordejo developer on a situation where he could work out his new GUI for NSM and having nsmd, with one or two extra patches maybe in a dedicated repository, not part of Non-Daw and without the NTK dependency. It was even the NON developer who suggested something like this. But in meantime, a small group of 'wise man', including the same Agordejo developer, orchestrated by the man with the many roles in this community (but who now strangely denies his undeniable role in this fork), where working on a huge take-over apparently... They dream big, unrealistically. They thought NSM patches would fall from the sky, with their fork. It proofs to be very hard already to create a modular environment with stable JACK tools, working together with one session API. Finally we have that one session API, but still, lot's of JACK applications are not stable or don't have a NSM patch. In other words, we don't need a revolution, we don't need big dreams, we need small fixes and especially we need to cherish this unique session landscape, with one session API. It's better to accept small annoyances, then to try to fix them with huge plans, cause you're only creating problems that are far larger then the small annoyances. A screwed session landscape. The last thing is under pressure obviously, with this fork. You see they're already changing the API and it's pretty likely they think they will need a big API change sooner or later and they won't hesitate to do it, that is what their way of forking tells us. They will find that excuse. It's a sad situation indeed. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] READ THIS IF YOU CARE ABOUT FREEDOM! Fwd: [LAA] Non DAW release including Non Session Manager (i.e. the real NSM)
‐‐‐ Original Message ‐‐‐ On Friday, January 29, 2021 8:07 PM, Robin Gareus wrote: > On 1/29/21 6:18 PM, rosea.grammostola wrote: > > > Linuxaudio community has a serious problem > > Yes, the problem is that people here are not discussing Linux Audio > Development :) > > "The Linux Audio Developers (LAD) list is dedicated to sound > architecture and application development for the Linux Operating > System." [1] > > Please refrain from any personal references. Neither your nor J.Liles > messages are acceptable here. Please focus on technical aspects > pertaining to Linux/libre audio projects. Thank you. > > PS. You may raise issues pertaining to policy [2] article 6 by > contacting the consortium [3]. > > [1] https://lists.linuxaudio.org/listinfo/linux-audio-dev > [2] http://linuxaudio.org/policy.html > [3] https://lists.linuxaudio.org/listinfo/consortium I see your formal point and of course you're right normally, but it's also a bit too easy. The fact that people use the linuxaudio consortium for a fork of a fellow Linuxaudio Developers project without consent, is a matter which touches the LAD community. I can imagine other developers wouldn't be happy if 'New-Ardour' would be 'officially released by linuxaudio.org'. And even if they won't care, others would for their software. Moreover, if you ban a developer from LAD, it's LAD related isn't it? If you're banned it means people block certain developers from a resource to discuss these technical LAD matters. The last message to the consortium is dated from 2018 and who guarantees me that the same persons aren't in charge there? I did choose for LAD, cause I think it's the best place to share my concerns and I still think it is. I do understand that most developers don't want to stick their heads into this and that it might end just here: go find a better place to issue this. Fine. I mean, I've also better things to do, but I think I've to speak up when I see a community transfer into a place where people who don't have the same opinion as some close core members, are more and more censored and where people misuse their neutral community roles for their own 'agenda'. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] READ THIS IF YOU CARE ABOUT FREEDOM! Fwd: [LAA] Non DAW release including Non Session Manager (i.e. the real NSM)
> > I am writing to you to let you know that I will hereby remove you from > this mailing list and permanently ban you from it as well. I'm not going to discuss whether a post does or does not comply to the rules of a mailinglist. But banning and certainly, banning for life, is almost never a good solution. But the problems are much deeper then this. It seems that small a group of people are deciding what is appropriate and what not and accidentally they're the same people behind the fork of non-session-manager and they now ban the developer of the project they forked. Read on. I hope we all agree that freedom of speech is a precious right. And people are free to raise issues and have firm criticism, even while the majority of people disagrees. Here a good amount of tolerance is needed and healthy. Linuxaudio community has a serious problem at the moment I think though, where people who have a certain opinion, which is shared by a core group backed up by a majority have more freedom of speech and more freedom to misbehave then people who are part of a minority or have a less shared opinion or doesn't belong to that core group. It's related to the problem I've raised yesterday on this LAD list, about the misuse of the linuxaudio consortium by a small group of people who are moderators of linuxaudio.org, github and apparently also the mailinglists. (I was not aware of any messages to LAA by the NON developer, timing is coincidence). Where the normal neutral linuxaudio consortium is now used to release and promote a fork. Whether you like it or not, those people have to admit there is a conflict of interests here and in healthy organizations and communities this should be avoided as much as possible. I don't think it will be fruitful to discuss the details of the fork here again or to do a competition who behaved the worst. And this isn't about his particular case, it's broader then that. This community has a problem when it comes to freedom of speech (not all are equal) and a conflict of interests (moderators ban developers and release their fork from the neutral linuxaudio consortium they moderate). It's basically a misuse of power by some core members of this community. Let's assume it's just a consequence of (group)emotions and ambitions, but it's hard to deny and it should be stopped and fixed. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] Misuse of linuxaudio.org consortium?
Hi LAD, I would like to raise a issue I've with what I think is a misuse of the consortium linuxaudio.org. As most of you know, the non-session-manager is forked a few months ago. This was not a fork in harmony with it's original developer and a part of the community, who worked on this project for more then 10 years and helped create a unique session environment where many users benefit from until today. Again? Get over it I hear you say. The license gives them the freedom to fork! I agree. But I've personally serious issues with how this is organized and presented and one thing goes beyond my personal views I think. Let's start with my personal view with saying that I don't like how they tried to replace non-session-manager by new-session-manager completely, in a for me 'Orwellian way'. This starts with the naming: Overall name: non-session-manager -> new-session-manager (new?) User interface: non-session-manager -> legacy-gui (legacy?) Ok, now I hear you say: they're free to choose whatever name they want, even if it's bad taste (which is subjective anyway) or if you think it has a 'Orwellian smell'. Moreover, you did issue this already some time ago. I agree. But where it goes really wrong I think, is the way how the name of 'linuxaudio.org' is used in the same deceptive manner. They present the very questionable and debatable fork as if it was released by linuxaudio.org. They release their fork with statements like: "Linuxaudio.org presents: New Session Manager Version x" "Released under the Linuxaudio umbrella" But since when does linuxaudio.org as consortium releases software? Or since when chooses linuxaudio.org as a consortium for a certain version of software? Since when does linuxaudio.org fork software from it's own LAD developers? I think linuxaudio.org has always been neutral about this and it never was a task for the linuxaudio.org consortium to release software or worse, to fork software from community developers and presents it as the 'new' and 'replacement' even while the original developer and a part of the community disagrees. It probably never crossed someones mind to do it this way. What has happened here, is in my view, a misuse of the name linuxaudio.org and people have misused their role as moderator and maintainer of linuxaudio.org and it's github page, to promote their own forked software version of a other LAD developer. Linuxaudio.org should stay neutral here and it should be considered 'unwanted', 'unhealthy' and 'not allowed' for people to use the name linuxaudio.org and maybe even the software structure of the consortium to promote a fork of someone else his work (without consent by the original LAD developer). The main developer of new-session-manager has his own place (laborejo.org) where he can puts his software and so also his fork. That's not the problem. But even if you place it on the linuxaudio github page for some reason, it's utterly wrong in my option, to present this fork as if it was released by the linuxaudio.org consortium. Regards, \r___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Alsa Modular Synth / AMS (bugs/NSM)
The git version seems to work fine: https://sourceforge.net/p/alsamodular/ams.git/ci/master/tree/ FYI: I stumbled upon a nice project with a nice sounding AMS. https://www.youtube.com/watch?v=gGIEzP0g5Ws ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Alsa Modular Synth / AMS (bugs/NSM)
On 12/7/20 3:37 PM, Paul Davis wrote: The much more obvious alternative is VCV Rack, with 2400+ modules, GPL'ed, totally cross platform and in most ways incredibly awesome. Ok, so that is really more awesome then AMS? I can't imagine. :) It doesn't have zita plugins, are you sure it sounds as good? I launched it last week indeed, but got crackled sound after 10 minuts, so I gave up then. Not bad to start simple with AMS anyway. Will checkout VCV Rack. Thanks for the suggestion. (But even if VCV Rack will suits my needs better, it's nice to have AMS working fine as LAU/LAD-community.) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] Alsa Modular Synth / AMS (bugs/NSM)
Hi, AMS is still interesting software. Going strong since 2002? I'm using it now to try to understand sound synthesis a little better and I've always liked the sound of it. So kudos to the developers! All the LV2 alternatives fail on me so far, moreover they're doesn't seems to be specially designed to be a modular synth like AMS, with it's nice cables. They seems to handle it more like, we have LV2 plugins, and look if you want you can modular synthesis with it (and then you encounter problems with the AMS-LV2 port). Anyway, I can't find a place to report AMS bugs. The issue tracker on SourceForge seems to be closed. I've reported two to Debian, but the maintainer hints to me that he is not able to solve it. Therefor I'll report them here. Maybe someone can look into it, that would be awesome. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976267 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976268 Regards, \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Release: New Session Manager Version 1.3
Ok, the cooled down version. My apology for the whitenoise. On 6/18/20 10:09 PM, Hermann Meyer wrote: If you are still interested in the future of Linux Audio Session Management you should really be happy that the Session Management is now in the hands of linuxaudio.org It's positive that people are still working on it indeed. It's also a good thing that people who prefer a QT gui, have a option to use Argodejo (new GUI for NSM). It's positive that nsmd and a gui (argodejo) will be easier accessible for regular Linux users and that it's chosen to be the session manager to focus on and to recommend for Linuxaudio. It's positive that they stick with the original NSM design, not reinventing the wheel. I'm not positive about the renaming to new-session-manager though. Non-session-manager is around for many years now, renaming it, adds confusion, also in relation to the existent documentation around on the Internet. I would really reconsider whether this change of name is needed and a wise thing to do. This part is also the 'hijackish' part for me, I know, it's free software, but still, it's a bit too much claiming NSM now with a whole plan behind it. It was Jonathan himself who suggested to put nsmd in it's own repository, so it would be easy to package Argodejo with nsmd for the variety of Linux distributions (the dependency on NTK and using waf made it difficult to get it in distros like Debian). It would be better to settle around with the original developer on how to organize this. But with a bit more patience, this drastic approach was not needed I think. If a fork turned out to be the only workable option, it might have been better to just fork nsmd and rename that, and don't touch the non-session-manager (GUI) at all. The version available on the new github repo is not a fair replacement for the original GUI at the moment anyway. It has problems with the graphics. It's also not the intention to develop it further, so why fork and rename it. The most important change is the change of the maintainers/developers of course. All though I'm sure it has positive sides in some aspects of it, don't forget we have NSM because of the work of Jonathan. He has come up with a session manager that works better then previous attempts, all though technically less complex it seems. Quite a accomplishment. It might sound good to have it labeled under 'linuxaudio' now, and aim for a more community driven development, but being nice and easy to each other isn't always good for the software. In fact, one of the reasons why NSM works, is because the original developer didn't make all kinds of compromises, for the sake of being a nice and friendly community. So, a new way of maintaining the software, isn't success guaranteed. If I compare Carla with the NON tools for instance, it's a totally different approach to software development. Where NSM is minimal and restricted, Carla has lots of features, even quite some experimental ones. I'm not judging about which approach is better, I'm happily using both of them, but I'm convinced that NSM is a success because it's minimal, restricted and without compromises. So for session management a minimal approach is surely a better one imho. Also building a GUI for NSM, is different coffee then actually judging about if and which features should be implemented in NSM and how that should be done. So, I've to see how this different maintainer-ship will turn out, but the original developer has proven that he 'gets it' when it comes to session management, for the others it's something we'll have to wait for and see. But not having the original designer of NSM as maintainer for whatever reason, I see it as a loss, not as improvement. Anyway, at the end of the day, the real important thing which improves user experience significantly at the moment is adding NSM support to applications. Hacking around applications without NSM support, without adding NSM support itself as I also see happening, is time spending on the wrong things and adds only to a more confusing, less stable and a worse user experience imho. I'm glad this Argodejo/NSM project doesn't seem to take this path and I hope it keeps that way. It has been said that there are not enough applications adding NSM support. I think a list of +- 30 applications isn't that bad at all actually, with quite some important ones included. For myself I've just a short list of applications that would have been nice to support NSM: Radium (in next release), Seq64/66 (work in progress), Hydrogen (work in progress), Carla-single (in roadmap), Muse (possibly maybe), Rakarrack, Sooperlooper, (Luppp needs a bugfix). In meantime, the original Non-Session-Manager with the NTK toolkit is still available, easy to build and as I prefer it above Argodejo myself, I'll still be heading to the NON project and more will do so most likely. So you can state that it will replace the
Re: [LAD] [LAU] Release: New Session Manager Version 1.3
On 6/18/20 10:01 PM, Paul Davis wrote: 1) "midnight" is a point in time in a given time zone that could correspond to any hour of the day somewhere around the planet 2) many programmers, especially those working on unpaid projects, work late at night your rush to assume ill-will here isn't a good look I should have said: symbolically, the perfect timing. I do apologize. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Release: New Session Manager Version 1.3
On 6/18/20 9:29 PM, Christopher Arndt wrote: Am 18.06.20 um 16:09 schrieb rosea.grammostola: [...] and releasing it at midnight. WTF, really. Yeah, WTF, really. As Filipe already pointed out, the time of day of the release is totally irrelevant and you keep on complaining about it without elaborating why it is significant. It was maybe better to keep that for a private e-mail exchange indeed. Let's say, for me personally it's been quite a hijack. But I've you've a hard time imagine what a midnight release could have to do with it, let's keep it that way and lets end that discussion here. :) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Release: New Session Manager Version 1.3
On 6/18/20 2:59 PM, Filipe Coelho wrote: NSM has been dormant for a while now until we (including you) recently starting pushing the discussion again. Coincidentally at the same time I did join the scene again? New NSM developments in Radium, Seq64, Hydrogen, Muse (maybe) and Rakarrack (cancelled). Bugfixes in Ardour6. You don't have to give me any praise for it, most was done in the background anyway and those developers should get it of course, but just ignoring the efforts, mailing me about NSM/Jonathan this week with so called concerns about his health and just hijack the project without even noticing nor discussing it and releasing it at midnight. WTF, really. Anyway, I've said what I wanted to say. Good luck with it. Cheers. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Release: New Session Manager Version 1.3
On 6/18/20 12:34 PM, Filipe Coelho wrote: Hi On 18/06/20 10:17, rosea.grammostola wrote: Quite a hijack... No credits to the original author in the release announcement, which is quite disrespectful. He did finally solve the session management problem on Linuxaudio with Non-Session-Manager after several attempts by some serious skilled programmers. Fair point. We did mention that it is based on the NON stuff, but not Jonathan's name. Sorry for that, it was not intentional. The "highjack" had to be done though, otherwise NSM would simply go nowhere. You even say yourself "I understand in some way that a fork is a logical consequence". We were very sad that the toxicity around one person was causing such harm to such great tool. In order to make NSM a real thing for linuxaudio (that is, not simply used by a tiny few users and apps), we *need* to get the community involved. To quote Jonathan himself: > Progress will not happen on its own. It must be forced along by individuals of power, wisdom, and vision; which we should all aspire to become. Release around midnight Europe time. Very classy guys. Why is release time important there? (serious question) We released after we had everything ready. And since we usually work on these things past official work-hours, that meant late in the day. I don't see how this changes anything, or tells anything about the status of the project. Disappointing. Might seem so from your point of you, but we tried, many many times to get everyone to work together here. You know I did a lot for NSM, and I'm probably the most likely the most active user in the community. Involved from the start of the project. I did a lot to improve the situation lately, with some success. I've had contact with both of you last week (IRC and mail). Nils sent me mail this week about NSM/Jonathan. Nothing about the fork. Besides the fact that I understand that at some point a fork was inevitable, next time you want to fork, just say it and make sure to do it in full daylight. This is acting like snakes on pro level and in a way very childish too. Quite disappointing for people who seems to have high social standards, but are lacking a mirror at home apparently. On a technical level, I'm glad you are aiming to be fully compatible with the original Non-session-manager (NSM). I'm just afraid that you're underestimating the task at hand and the accomplishments being made here though. Not giving the original author the credits he deserves, might be a sign of it as well. From personal experience, I've still have to find someone else besides the original author of NSM, who understands why NSM works as a session manager. It works I think, because it's simple and has clear rules. I see a urge for new features, which are potentially harmful for the success of NSM. When I didn't use Linuxaudio for years and restarted it, it was quite a horrible experience. JACK standalone applications do have all kinds of features, but where crashing on me constantly (the nice thing about NSM, is that you've it back in one click). Totally unusable to make music with. I'm personally not waiting for new non-essential NSM features, which are making my setup less predictable, more resources consuming and less stable. Raysession, I've no confidence in it. I said enough about it. Better spent your time in NSM support for clients. You recommend Argodejo as GUI on the github page. I've a very hard time finding it better then the default NSM GUI. The simple view is not that simple anymore if you've a lot of sessions. The advanced view, is more complex then the original GUI, because it gives you so much more information. Duplicate was renamed as 'save as', which might cause dataloss for people who expect it to behave as 'save as' in other applications. Might be personal preferences, but all these small things doesn't make me very enthusiastic about NSM without the original author. A other related experience. Feature request for Radium. NSM support in Radium, which is great. Author did implement accidentally server client osc messages. As a consequence he decides to give Radium session manager functionality as well. I think this design approach will harm a reliable and predictable NSM session environment for the user at the end. Anyway, wasted too much time on it already probably. Cheers. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Release: New Session Manager Version 1.3
Quite a hijack... No credits to the original author in the release announcement, which is quite disrespectful. He did finally solve the session management problem on Linuxaudio with Non-Session-Manager after several attempts by some serious skilled programmers. Release around midnight Europe time. Very classy guys. I've had e-mail contact with Nils twice about NSM this week. No word about this hijack/fork. All though I understand in some way that a fork is a logical consequence and I'm not totally against (maybe the timing), you guys really act like little boys or girls in high-school. Disappointing. On 6/17/20 11:52 PM, softw...@linuxaudio.org wrote: Linuxaudio.org presents: New Session Manager Version 1.3 New Session Manager (NSM) is a tool to assist music production by grouping standalone programs into sessions. Your workflow becomes easy to manage, robust and fast by leveraging the full potential of cooperative applications. It is a community version of the "NON Session Manager" and free in every sense of the word: free of cost, free to share and use, free of spyware or ads, free-and-open-source. You can create a session, or project, add programs to it and then use commands to save, start/stop, hide/show all programs at once, or individually. At a later date you can then re-open the session and continue where you left off. All files belonging to the session will be saved in the same directory. New-Session-Manager is already included as binary package in Archlinux and KXStudio and will eventually replace Non-Session-Manager. You can find the source release on Github: https://github.com/linuxaudio/new-session-manager/releases/tag/v1.3 Bullet Points * Drop-In replacement for the non-session-manager daemon nsmd and tools (e.g. jackpatch) * Simple and hassle-free build system to make packaging easy * Possibility to react to sensible bug fixes that would not have been integrated into original nsmd * Stay upwards and downwards compatible with original nsmd * Conservative and hesitant in regards to new features and behaviour-changes, but possible in principle * Keep the session-manager separate from the other NON* tools Mixer, Sequencer and Timeline. * Protect nsmd from vanishing from the internet one day. * The goal is to become the de-facto standard session manager for Linux distributions Changes since non-session-manager v1.2 (2017-07-08) * Rebranding to "new session manager" * Upstream GUI tools "non-session-manager" and "nsm-proxy" converted to standard FLTK instead of a custom toolkit * New message /nsm/gui/session/root raises NSM_API_VERSION_MINOR from 0 to 1 (1.0 -> 1.1) * Changed build system to meson * License upgraded to GPLv3 * Simplified file structure * Fix compiler warnings. This is a joint release from multiple people under the linuxaudio.org "brand". https://github.com/linuxaudio/new-session-manager Greetings, dvzrv, falktx and nils ___ Linux-audio-user mailing list linux-audio-u...@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-user ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] Ableton Link
Hi all, I saw that Supercollider 3.11 beta 1 comes with Ableton Link support https://github.com/supercollider/supercollider/releases/tag/3.11-beta1 I know Rui Nuno Capela is working on Jack Link, a Ableton Link implementation for Jack (Transport). Interesting developments to keep an eye on. Ableton Link might be fitting well in the Linuxaudio environment with all those (small) applications that support Jack (Transport). Regards, \r Ableton Link presentation at LAC18 https://media.ccc.de/v/lac2018-42-ableton_link_a_technology_to_synchronize_music_software pEpkey.asc Description: application/pgp-keys ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Any Rakarrack developers around here?
On 26-02-2020 22:51, rosea.grammostola wrote: >> That is an interesting trend isn't it? Certainly the presets are much >> more convenient to use right from rakarrack than using the plugins. I >> had hoped my project would be used more, but OTOH I use them and I >> don't regret the effort. > It's interesting for sure... > > Imho working with all the JACK applications can be a pain on Linux, but > with nsm support, the experience is much better. And then standalone > applications are preferable in certain situations actually. If I would > need one instance of Zynaddsubfx, I would always grab the standalone > version. If I need more instances, I might switch to Carla instead and > grab the plugin. > > On the other hand, I know people are using Rakarrack, because you can > launch multiple instances and chain them together to create something > interesting. Actually I always thought doing automation with JACK standalone applications was a huge disadvantage compared with plugins. But it's actually good possible to sent midi cc automation from a DAW to a JACK standalone softsynth like Zynaddsubfx. Or I was ignorant, or I'm still ignorant, but I don't see the problem not so much anymore. :) By the way, I've heard people are using your plugins too, so don't worry too much about it. ;) pEpkey.asc Description: application/pgp-keys ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Any Rakarrack developers around here?
On 26-02-2020 22:30, Spencer Jackson wrote: > It would be a nice feature add. It's highly unlikely to happen though > unless someone outside of the project does the work, I'm not even sure > they are active enough to accept a pull request. Yes, I probably need to search for someone else outside the project. Volunteers raise your hand please! :) You can clone the git repo at least, if that's what you mean: https://sourceforge.net/p/rakarrack/git/ci/master/tree/ > > > I saw your plugins, but even with plugins, users seems to prefer > > Rakarrack as a whole for certain composition work. > > > > That is an interesting trend isn't it? Certainly the presets are much > more convenient to use right from rakarrack than using the plugins. I > had hoped my project would be used more, but OTOH I use them and I > don't regret the effort. It's interesting for sure... Imho working with all the JACK applications can be a pain on Linux, but with nsm support, the experience is much better. And then standalone applications are preferable in certain situations actually. If I would need one instance of Zynaddsubfx, I would always grab the standalone version. If I need more instances, I might switch to Carla instead and grab the plugin. On the other hand, I know people are using Rakarrack, because you can launch multiple instances and chain them together to create something interesting. pEpkey.asc Description: application/pgp-keys ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Any Rakarrack developers around here?
> > Do you have a specific question or are you just curious? I wanted to check if there was any interest in adding non-session-manager (nsm) support to Rakarrack. Seems to be a nice candidate for it and it's mentioned by people if you ask them which applications should get nsm support. Interesting combi with Guitarix as well probably. I saw your plugins, but even with plugins, users seems to prefer Rakarrack as a whole for certain composition work. pEpkey.asc Description: application/pgp-keys ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] Any Rakarrack developers around here?
Hi, First, congratulations, Rakarrack is still actively used by people, even though the application itself isn't that active anymore. :) Any (former) Rakarrack developers on this list? Regards, \r pEpkey.asc Description: application/pgp-keys ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org https://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] New Jack / LV2 Host with socket support
On 05/28/2013 05:04 PM, Bruno Gola wrote: On Tue, May 28, 2013 at 10:53 AM, Thijs van severen thijsvanseve...@gmail.com wrote: hi all a question about this host app: would this allow me to control the calf LV2 plugins using an external midi controller ? (map a midi 'knob' to a LV2 parameter) we have plans to support a midi-mapping feature, but not now :( It would be nice if this LV2 host would have non-session-manager (nsm) support. Best regards, \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] New Jack / LV2 Host with socket support
On 05/28/2013 06:28 PM, rosea.grammostola wrote: On 05/28/2013 05:04 PM, Bruno Gola wrote: On Tue, May 28, 2013 at 10:53 AM, Thijs van severen thijsvanseve...@gmail.com wrote: hi all a question about this host app: would this allow me to control the calf LV2 plugins using an external midi controller ? (map a midi 'knob' to a LV2 parameter) we have plans to support a midi-mapping feature, but not now :( It would be nice if this LV2 host would have non-session-manager (nsm) support. Ah should have looked better. nsm support makes little sense here I'm afraid. Sorry for the noise. \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] NSM support: progress, wishlist
On 05/21/2013 01:06 AM, Robin Gareus wrote: On 05/21/2013 12:13 AM, geoff wrote: conversations with the one known in this thread as rosea.grammostola What is that supposed to mean Paul? g It means rosea.grammostola is not his real name :) In real life it's Dirk. :) Anyway, 'optional-gui' in NSM seems to be especially (maybe even only?) useful for small jack standalone apps like AMS, LisaloQT, Zynaddsubfx etc. Other opinions about optional gui in nsm? \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] NSM support: progress, wishlist
On 05/15/2013 11:12 PM, David Santamauro wrote: On 05/15/2013 02:41 PM, Dan wrote: To my knowledge (from direct IRC interaction with e.g. torben hohn) there is very little interest by the original jack-session devs to continue, support and fix it. Just from reading LAD I did not realize that. Is this (de-facto) deprecation documented anywhere? Very good question. Where are the tides swelling? Are you saying that you guys are plain (outside Ladish) Jack-Session users? I don't think this will get announced officially, Jack-Session is out there, do with it what you want, but don't expect heavily development on it like you see with NSM. By the way, I used Laborejo in NSM today and it used the 'optional GUI' functionality in the NSM protocol. This is just great! I was thinking a few days ago 'all those small apps on your desktop is an disadvantage of one-task-one-tool. You can hide plugin.' But this hide/show GUI option seems to solve just that! http://non.tuxfamily.org/nsm/API.html#n:1.2.4.1 Regards, \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] NSM support: progress, wishlist
On 05/18/2013 01:37 PM, Thijs van severen wrote: i must confess : i'm also using jack session :-) But you're coming from far, Garageband wasn't it (o no that was a friend of yours right)? ;) Anyway, floss development can be fast, very fast. Rui implemented 'nsm optional-gui' functionality in qtractor and his v1 stuff already, oh my! :) Thanks! \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] NSM support: progress, wishlist
Hi, FYI Qmidiarp and AMS has nsm support now. ams: https://github.com/royvegard/ams On 05/01/2013 11:38 AM, rosea.grammostola wrote: - Rakarrack - PHASEX - Ingen - Guitarix - Giada and/or Kluppe (?) (JackTransport would be nice too) - HarmonySEQ - Muse - Hydrogen - ... - ... I'm sure I forgot quite a few... From the above projects, Rakarrack doesn't seems to be actively developed. So if an dev outside the project wants to add nsm support, you're welcome. (That's true for all Linuxaudio software I guess :) ) I'm not sure whether there're (technically/workflow) reasons to add nsm support if there's already an plugin (LV2/DSSI) version of it. Assuming the plugin version has no limitations compared to the standalone version, you can use the plugin version in plugin hosts with nsm support (Carla atm). If you think it would make a difference, I'd be interested for your argumentation. Best regards, \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] NSM support: progress, wishlist
On 05/15/2013 04:36 PM, Jeremy Jongepier wrote: Yes, Yoshimi for instance ;) I'll take another look at http://non.tuxfamily.org/nsm/yoshimi-nsm.patch and dig up the discussion again about jack-session vs NSM. The aforementioned patch namely removes all jack-session support and I'm not sure if I want that. I don't think Jack-Session is used much these days, tell me if I'm wrong. If they still exist, I would challenge the JS users to try NSM, good chance you'll prefer the latter. If JS is used, it's used within Ladish I think. Remember that Ladish will support nsm in the future. However, I don't think JS needs to be removed to add nsm support. There're more apps which supports both (e.g. added JS first and then switched to NSM without removing JS). Removal of JS might be better for tactical reasons though. You can argue that it's better for the LAU/LAD community if there's one session API to support. Best regards, \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ANN] - Introducing the MOD - Your LV2 plugins at your feet
You can see all costumer related info on the website www.portalmod.com/en http://www.portalmod.com/en and you can watch a video of the prototype working here http://portalmod.com/blog/2013/03/video-1-testando-o-prototipo/ The core software inside the MOD is Open Source and is being published at github (https://github.com/portalmod). [] We hope you all like what we are doing and we would love to discuss further details with you. Kind Regards Gianfranco Ceccolini The MOD Team In which way to you support/stimulate FLOSS LV2 plugins and/or proprietary LV2 plugin? I wonder if this project will stimulate the development of FLOSS or proprietary LV2 plugins. \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Kontakt sampler format (and others like EXS24)
On 08/31/2012 04:56 PM, Nils wrote: On Fri, 31 Aug 2012 14:43:13 +0100 Harry van Haarenharryhaa...@gmail.com wrote: On Fri, Aug 31, 2012 at 1:03 PM, Nilsl...@nilsgey.de wrote: The direct and naive solution would be a reversed engineered kontakt sample engine, yes. Very naive. The community could approach NI and ask if they're intrested in supporting a Linux version of Kontact? I volunteer to write the email, and if they laugh then what harm done... Opinions? Regardless if it was done or in the past or not It would be very nice of you to write an email to them. Maybe an email from linuxaudio.org works better? Someone who speaks in name of an organization? \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] LV2 standalone / Session support / (Vee One)
Hi, Thanks Rui for the 'Vee One prototypes', released as LV2 plugins and standalone verions. http://www.rncbc.org/drupal/node/549 It's nice that the user has the choice of using the sampler/synth as a plugin or as standalone application. Another nice thing in this release is that you included Session Management support in the standalone versions, JackSession in this case. This makes me wondering: Why does every developer makes his own little single instance host for his standalone version of the LV2 plugins? Why isn't there a standard single-instance LV2 host which can be used by all the developers for their standalone versions of the LV2 plugins they make? A small host, devs can link to and which works like some kind of run-time dependency of the standalone version. Didn't have DSSI some kind of system like that? One of the big advantages of this is that you could eliminate a large part of the session problem in the Linuxaudio ecosystem. Every new release of a LV2 standalone application is another application which needs to be patched for some kind of Session Management. This is cumbersome for devs and users. If that standard single instance LV2 host supports Session Management by default (NSM/Ladish/JackSession/whatever), you solve a significant part of the problems you encounter when working with standalone Jack apps on Linux. 1) Users have the choice to use the plugin as standalone version, with the SM functionality; 2) Developers don't have to patch their standalone version with SM support; 3) Users have more freedom to use the SM they want, because most new LV2 standalone versions will support the most popular SM systems. Best regards, Dirk (alias Rosea Grammostola) ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] out now petri-foo 0.1.85 / NSM
On 08/01/2012 01:52 PM, Louigi Verona wrote: Is JACKSession really dead? And fellas, to a non-coder, can you explain why isn't session handling done through JACK, which seems like a logical thing to do? I'm not a coder. Advantages are imo: 1) you can leave JACK apps outside a session on purpose This is useful for instance when you have JACK apps running all the time in your studio, switching sessions shouldn't force you to stop that application. 2) crashing JACK doesn't corrupt your session probably 3) it works also with other audio servers like KLANG :) Regards, \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] out now petri-foo 0.1.85 / NSM
On 08/02/2012 03:17 PM, Paul Davis wrote: On Thu, Aug 2, 2012 at 5:43 AM, rosea.grammostola rosea.grammost...@gmail.com mailto:rosea.grammost...@gmail.com wrote: 3) it works also with other audio servers like KLANG :) i imagine that this is supposed to be facetious, but if you had understood anything about KLANG it should have been that it is NOT intended to be, or involve, a server. Yes it is a joke. My comment (and KLANG probably too). But there is some truth in it too I think. NSM doesn't depend on JACK, so it works with JACK1, JACK2 and with a hypothetical other audio lowlatency system. Regards, \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] out now petri-foo 0.1.85 / NSM
On 08/01/2012 11:53 AM, James Morris wrote: On 01/08/12 rosea.grammostolarosea.grammost...@gmail.com wrote: On 08/01/2012 03:30 AM, James Morris wrote: On 30/07/12 rosea.grammostolarosea.grammost...@gmail.com wrote: On 07/30/2012 03:12 AM, James Morris wrote: (1.0) Non Session Management support Nice to see a dev who's taking this up. Session management a 'must have' for jack standalone applications and imho NSM is the best option for this. Woohoo there is now a grand total of 5 apps supporting it: http://wiki.linuxaudio.org/apps/categories/nsm I count 7, but yeah despite your sarcasm, that's good news indeed, that's already more support then LASH had in it's first days. But the nice and essential thing about NSM is that it's support apps without a state, and apps without NSM support via nsm-proxy. Moreover NSM-proxy supports Ladish level 1 also. LASH failed despite 26 apps supporting it: http://wiki.linuxaudio.org/apps/all/lash The problem with LASH is that it has obvious (technical) flaws. Session managers today are much better. Imo NSM has a great technical design, with advantages compared to other session api's and without (essential) technical flaws. If you think that all the apps apps.linuxaudio.org will support a session api, then you're not very realistic. That's why it's essential that NSM support apps without NSM support and apps without a state in a user friendly way. I guess. But for those who need to play around with stuff before they find what they can use to start being productive it's not good. I don't see what you mean. You've a list of apps with NSM support. You can use those in the NSM session. Other apps you can launch via nsm-proxy. If you want to use Ladish l1, look at the list of apps with ladish l1 support. No session manager, that's a problem. Users play around with stuff and never become productive. Standalone Jack applications are nice, but without good session support modular linuxaudio is a joke to say it frankly. That many apps already have a form of session management is one of the problems for NSM. What should a developer do when attempting to support NSM in an application which already has Jack Session support and LASH support? It increases the complexity of what the user interface has to deal with. First, it makes it far more easy to implement NSM. The time consuming 'search work' for adding session support is already done. Second, I assume that it is possible to support more session api's in one application. Maybe it's actually better - at least most people are aware now of the problems with the other session managers In Petri-Foo it wasn't so much of a problem. I simply removed support for LASH because there was no user base to tell me otherwise. But can I do that with other apps? I'm looking at jack-rack for instance. See above. Regards, \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] out now petri-foo 0.1.85 / NSM
On 08/01/2012 12:41 PM, James Morris wrote: On 01/08/12 rosea.grammostolarosea.grammost...@gmail.com wrote: On 08/01/2012 11:53 AM, James Morris wrote: .. LASH failed despite 26 apps supporting it: http://wiki.linuxaudio.org/apps/all/lash The problem with LASH is that it has obvious (technical) flaws. Session managers today are much better. Imo NSM has a great technical design, with advantages compared to other session api's and without (essential) technical flaws. If you think that all the apps apps.linuxaudio.org will support a session api, then you're not very realistic. That's why it's essential that NSM support apps without NSM support and apps without a state in a user friendly way. I guess. But for those who need to play around with stuff before they find what they can use to start being productive it's not good. I don't see what you mean. You've a list of apps with NSM support. You can use those in the NSM session. Other apps you can launch via nsm-proxy. If you want to use Ladish l1, look at the list of apps with ladish l1 support. I would but linuxaudio.org seems to have gone down :-( That many apps already have a form of session management is one of the problems for NSM. What should a developer do when attempting to support NSM in an application which already has Jack Session support and LASH support? It increases the complexity of what the user interface has to deal with. First, it makes it far more easy to implement NSM. The time consuming 'search work' for adding session support is already done. Second, I assume that it is possible to support more session api's in one application. The point I was making is supporting multiple session handlers makes the application more complex than it necessarily needs to be and increases the amount of code that needs to be maintained. If LASH has so many faults and nobody is maintaining LASH itself, by dropping support for LASH in clients we kill two birds with one stone: 1) there's less maintenence work for devs to do - always good and 2) it directs users to better solutions such as NSM. But I don't actually know what user base exists for LASH. I want to drop support for it but will revolting users castrate me for it? LASH is dead, period. The only reason not to remove LASH is that Ladish supports it. But because Ladish will support NSM in future, it might be no problem to completely remove LASH if you add NSM. JackSession is also more or less dead, because of some flaws in practical usage and because of the fact that it is more or less no longer maintained any longer. Which is good imo, it's better to have one session api then a lot. Ladish supports JS, but other then that there is little reason for not replacing JS with NSM. It might be good for Linuxaudio if the JackSession devs declare JackSession to be dead. Regards, \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [ann] out now petri-foo 0.1.85 / NSM
On 08/01/2012 03:30 AM, James Morris wrote: On 30/07/12 rosea.grammostolarosea.grammost...@gmail.com wrote: On 07/30/2012 03:12 AM, James Morris wrote: (1.0) Non Session Management support Nice to see a dev who's taking this up. Session management a 'must have' for jack standalone applications and imho NSM is the best option for this. Woohoo there is now a grand total of 5 apps supporting it: http://wiki.linuxaudio.org/apps/categories/nsm I count 7, but yeah despite your sarcasm, that's good news indeed, that's already more support then LASH had in it's first days. But the nice and essential thing about NSM is that it's support apps without a state, and apps without NSM support via nsm-proxy. Moreover NSM-proxy supports Ladish level 1 also. LASH failed despite 26 apps supporting it: http://wiki.linuxaudio.org/apps/all/lash The problem with LASH is that it has obvious (technical) flaws. Session managers today are much better. Imo NSM has a great technical design, with advantages compared to other session api's and without (essential) technical flaws. If you think that all the apps apps.linuxaudio.org will support a session api, then you're not very realistic. That's why it's essential that NSM support apps without NSM support and apps without a state in a user friendly way. Just not enough developers with free time and brain cells not owned by their employers to make it work. That's not totally true. If you count all the apps with a form of session management support, you can't really blame their efforts. On the other hand, it's true: session management seems to be primarily a users problem not a developers problem, unfortunately. It's kind of a pity that NSM was released not earlier. Because of other session api's, devs are hesitated to add NSM support, but I'm confident that this will change soon. Speaking for myself, I start *all* the linuxaudio applications I use (with NSM support or via NSM-proxy) in NSM, because it works. And that's why I am optimistic, it's just great that all those years we have something that just works! :) Best regards, \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] [ann] out now petri-foo 0.1.85
On 07/30/2012 03:12 AM, James Morris wrote: (1.0) Non Session Management support Nice to see a dev who's taking this up. Session management a 'must have' for jack standalone applications and imho NSM is the best option for this. Best regards, \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] How to get NSM?
On 04/11/2012 02:55 AM, Mark McCurry wrote: I've seen the lengthy discussion of NSM and decided I'd like to give it a whirl, but I cannot figure out where the code lives. As far as I can see http://non.tuxfamily.org/nsm/ has no mention of how to get the code. So how do I get (git?) it? Thanks Its code seems to currently be in the same repo as Non-DAW. Here is the clone command: git clone git://git.tuxfamily.org/gitroot/non/daw.git Apart from the master branch, there is also a next branch with new stuff and a nsm-proxy branch for the new proxy app. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] How to get NSM?
On 04/11/2012 12:14 PM, thijs van severen wrote: 2012/4/11 rosea.grammostola rosea.grammost...@gmail.com mailto:rosea.grammost...@gmail.com On 04/11/2012 02:55 AM, Mark McCurry wrote: I've seen the lengthy discussion of NSM and decided I'd like to give it a whirl, but I cannot figure out where the code lives. As far as I can see http://non.tuxfamily.org/nsm/ has no mention of how to get the code. So how do I get (git?) it? Thanks Its code seems to currently be in the same repo as Non-DAW. Here is the clone command: git clone git://git.tuxfamily.org/__gitroot/non/daw.git http://git.tuxfamily.org/gitroot/non/daw.git Apart from the master branch, there is also a next branch with new stuff and a nsm-proxy branch for the new proxy app. are there plans to get it in KXstudio repo's ? afaik the maintainer will add NSM support to Carla (?), so I'm sure it will. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] How to get NSM?
On 04/11/2012 12:55 PM, Emanuel Rumpf wrote: Am 11. April 2012 12:08 schrieb rosea.grammostolarosea.grammost...@gmail.com: git clone git://git.tuxfamily.org/gitroot/non/daw.git Apart from the master branch, there is also a next branch with new stuff and a nsm-proxy branch for the new proxy app. proxy app - what's that ? If you build the nsm-proxy branch, you're able to add the client nsm-proxy, which allows you to load apps without a state or without NSM support and add some arguments to it as you would do on the command line. \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
It might be a good idea to discuss NSM (and it's implementation) and compare it with other Session Managers, at LAC2012. Such a conference could be a nice opportunity to share ideas to improve Linuxaudio session management in general. Unfortunately I'm not able to attend this year. For those who go, have fun! :) 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/11/2012 03:18 PM, Dave Phillips wrote: Hey Dirk, We'll miss you ! I still tell people about the fellow who approached me on a train platform in Dublin and asked if I was Dave Phillips. Hehe, I did the same when I saw Bono standing at Dublin central. He still tells his friends about it to. Must feel good apparently, when you're famous and people you have no clue about, recognize you in the middle of a crowd :) Have a good time! ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] How to get NSM?
On 04/11/2012 01:02 PM, rosea.grammostola wrote: On 04/11/2012 12:55 PM, Emanuel Rumpf wrote: Am 11. April 2012 12:08 schrieb rosea.grammostolarosea.grammost...@gmail.com: git clone git://git.tuxfamily.org/gitroot/non/daw.git Apart from the master branch, there is also a next branch with new stuff and a nsm-proxy branch for the new proxy app. proxy app - what's that ? If you build the nsm-proxy branch, you're able to add the client nsm-proxy, which allows you to load apps without a state or without NSM support and add some arguments to it as you would do on the command line. \r This script should work to load LinuxSampler as binary in a nsm-proxy. The lscp file should be loaded via the argument option in the nsm-proxy. Only problem I have, it doesn't kill LinuxSampler, when I stop the nsm-proxy or the session. I probably miss something, maybe someone can test it too. #!/bin/bash linuxsampler LSPID=$! # wait for LS to init sleep 4; # tell it what file to load cat $1 | nc localhost #handle SIGTERM from NSM by killing LS. trap 'kill -TERM $LSPID' SIGTERM #wait for LS to die naturally wait $LSPID ___ 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/06/2012 09:06 PM, Joel Roth wrote: On Wed, Apr 04, 2012 at 10:12:53PM +0200, rosea.grammostola wrote: Afaik, NSM gives us all we users need when it comes to LAU session management Correct me if I'm wrong. It would be great if the core functionality of NSM could be separated out from the GUI to support console users and environments where X may not be available. So that's already the case. Anyway thanks for trying :) Only developers are able to convince me on fundamental flaws of the NSM design atm. In this regard, it might be good if JackSession developers speak out about the current situation, now we have NSM and JackSession. They probably see those fundamental flaws or disadvantages in NSM. Or they maybe see particular advantages of JackSession or even NSM. Let me summarize my personal findings as a JackSession and NSM user: Personally I saw it as an advantage of JackSession, that it has JACK involved and that it only needs the JACK dependency. After the comments by Fons and by trying NSM myself, I think that it is an advantage of NSM instead, that it is independent of JACK. It's more easy to add apps without JACK support to the session and to keep apps with JACK support outside the session (by purpose). It gives you as a user more freedom and flexibility overall and so I think it's a better design choice. These advantages out weights the disadvantage of having one extra dependency to support NSM (liblo). In terms of workflow, I prefer NSM above JackSession. Not only the fact that it is possible to easily launch apps without session support (without conf files), but also that it does what you expect from a session manager, OOTB. Close applications, fast, easy and safe saving. Quick and easy changing from one session to another etc. The fact that NSM asks supported clients to act coherently and predictable is another advantage. I think it gives you as a user a simple and clear workflow. An disadvantage of this might be that a little more is expected from the devs of the clients, but as far as I understood that's isn't much extra effort to support it and also there are no fundamental objections yet, apart from the fact apps which doesn't have a centralized save location (qtractor), have more problems with this. I think this is a problem in that app as others pointed out. Moreover there are not many apps with this behavior. In summary and to conclude: After using Ladish and especially JackSession, I think NSM is the best solution for the session puzzle so far and likely for the coming years. This is a personal user perspective, devs could think otherwise, but I didn't see a good reason for this so far. Thanks. The list is yours again ;) \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/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 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
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 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 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 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 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 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 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
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 03/30/2012 12:27 PM, Paul Davis wrote: re: the central media location - in rui's defense i'd like to point out that it took cubase more than 10 years to move away from something fairly close to his model. Ok, that will be 5 yrs for Rui then ;) Serious though. What does this mean for Qtractor and NSM in theory? Qtractor can't apply to the strict session saving rules of NSM atm and not in the near future? If so, is there a solution for this from the perspective of Qtractor and NSM? Are there other applications with this same 'problem'? Best regards, \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
Apart from the Qtractor scenario (which seems not to be an impossible hurdle to take), there is one question left for me and that is: *Is it needed to remove JackSession support, in order to add NSM support?* I don't expect this to be true, but afaik JackSession is disabled in the NSM Yoshimi patch. I suspect that distro maintainers wants all available session options to be enabled for their users. Other question might be if NSM is able to run crossplatform, but I believe the answer is YES (correct me if I'm wrong). Then of course you have the issue whether devs wants to apply to the strict NSM rules, but apart from issues reported by Rui, I didn't hear any arguments against it from developers yet. 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 03/30/2012 03:48 AM, J. Liles wrote: The point of those guidelines is to allow users to know*exactly* what behavior they can expect. The chief difficulty I had with implementing LASH support in programs was that there was no answer as to what 'Save', 'Open', 'New', etc. should do when running under LASH. Left, as is, the effect of these operations would vary depending on how individual applications store their state (whether fully in RAM, in a fixed location on disk, etc.). This scenario is an absolute nightmare for both implementers and users. If following a few simple rules to disable certain menu options is enough to remove this ambiguity entirely, then why is that so hard for you to accept? Do you*want* to make things ambiguous and impossible to predict? I know I don't. The rules are not there to be draconian and imposing--They are there to allow people to have confidence in what running under session management means regarding where their data is stored. Makes me wonder about JackSession. Does it have the same problem here compared to LASH? \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On 03/24/2012 11:09 PM, Fons Adriaensen wrote: 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). 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On 03/29/2012 12:02 PM, Louigi Verona wrote: my 2 cents from user perspective: I know where I save my files, I know where my sample collections are. i know that if i delete my sample collection, sessions won't load. i don't need any program to tell me that. in fact, in using FL Studio or Cubase or LMMS you have the same situation. a project can use same files as another project and if you damage those files - well, sorry. 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. I do not see any reason for complications in session manager design. i agree with david, all of this is unnecessary and only will make NSM a session manager developers would be reluctant to adopt. 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On 03/29/2012 12:29 PM, thijs van severen wrote: 2012/3/29 Louigi Verona louigi.ver...@gmail.com mailto:louigi.ver...@gmail.com my 2 cents from user perspective: I know where I save my files, I know where my sample collections are. i know that if i delete my sample collection, sessions won't load. i don't need any program to tell me that. in fact, in using FL Studio or Cubase or LMMS you have the same situation. a project can use same files as another project and if you damage those files - well, sorry. I do not see any reason for complications in session manager design. i agree with david, all of this is unnecessary and only will make NSM a session manager developers would be reluctant to adopt. louigi verona. On 3/29/12, rosea.grammostola rosea.grammost...@gmail.com mailto:rosea.grammost...@gmail.com wrote: On 03/24/2012 11:09 PM, Fons Adriaensen wrote: 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). 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 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 Iirc it was just an idea to do make that. It doesn't exist yet. An overview would be good imo. It would be even better if such a matrix could help in making a decision for the best SM API to support, at the moment. As a user who wants to use session API X, I don't have much benefits if applications supports session API Y. Unless I decide to use Ladish, personally that wouldn't be my choice though. \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On 03/29/2012 11:41 AM, rosea.grammostola wrote: On 03/29/2012 12:02 PM, Louigi Verona wrote: my 2 cents from user perspective: I know where I save my files, I know where my sample collections are. i know that if i delete my sample collection, sessions won't load. i don't need any program to tell me that. in fact, in using FL Studio or Cubase or LMMS you have the same situation. a project can use same files as another project and if you damage those files - well, sorry. Ah your reply was a reaction on the 'saving large file in NSM discussion'. I would suggest you to quote the relevant part of the discussion and then type your reply, otherwise it's hard follow the discussion(s). \r 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. I do not see any reason for complications in session manager design. i agree with david, all of this is unnecessary and only will make NSM a session manager developers would be reluctant to adopt. 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On 03/29/2012 01:16 PM, thijs van severen wrote: 2012/3/29 rosea.grammostola rosea.grammost...@gmail.com mailto:rosea.grammost...@gmail.com On 03/29/2012 12:29 PM, thijs van severen wrote: 2012/3/29 Louigi Verona louigi.ver...@gmail.com mailto:louigi.ver...@gmail.com mailto:louigi.verona@gmail.__com mailto:louigi.ver...@gmail.com my 2 cents from user perspective: I know where I save my files, I know where my sample collections are. i know that if i delete my sample collection, sessions won't load. i don't need any program to tell me that. in fact, in using FL Studio or Cubase or LMMS you have the same situation. a project can use same files as another project and if you damage those files - well, sorry. I do not see any reason for complications in session manager design. i agree with david, all of this is unnecessary and only will make NSM a session manager developers would be reluctant to adopt. louigi verona. On 3/29/12, rosea.grammostola rosea.grammost...@gmail.com mailto:rosea.grammost...@gmail.com mailto:rosea.grammostola@__gmail.com mailto:rosea.grammost...@gmail.com wrote: On 03/24/2012 11:09 PM, Fons Adriaensen wrote: 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). 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 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 Iirc it was just an idea to do make that. It doesn't exist yet. An overview would be good imo. It would be even better if such a matrix could help in making a decision for the best SM API to support, at the moment. As a user who wants to use session API X, I don't have much benefits if applications supports session API Y. Unless I decide to use Ladish, personally that wouldn't be my choice though. 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 ? A matrix is nice for a quick overview, but for such a decision you need more in depth information and argumentation. A matrix could only function as a tool to help with the decision. \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On 03/29/2012 01:25 PM, thijs van severen wrote: 2012/3/29 rosea.grammostola rosea.grammost...@gmail.com mailto:rosea.grammost...@gmail.com On 03/29/2012 01:16 PM, thijs van severen wrote: 2012/3/29 rosea.grammostola rosea.grammost...@gmail.com mailto:rosea.grammost...@gmail.com mailto:rosea.grammostola@__gmail.com mailto:rosea.grammost...@gmail.com On 03/29/2012 12:29 PM, thijs van severen wrote: 2012/3/29 Louigi Verona louigi.ver...@gmail.com mailto:louigi.ver...@gmail.com mailto:louigi.verona@gmail.__com mailto:louigi.ver...@gmail.com mailto:louigi.verona@gmail. mailto:louigi.verona@gmail.com mailto:louigi.verona@gmail.__com mailto:louigi.ver...@gmail.com my 2 cents from user perspective: I know where I save my files, I know where my sample collections are. i know that if i delete my sample collection, sessions won't load. i don't need any program to tell me that. in fact, in using FL Studio or Cubase or LMMS you have the same situation. a project can use same files as another project and if you damage those files - well, sorry. I do not see any reason for complications in session manager design. i agree with david, all of this is unnecessary and only will make NSM a session manager developers would be reluctant to adopt. louigi verona. On 3/29/12, rosea.grammostola rosea.grammost...@gmail.com mailto:rosea.grammost...@gmail.com mailto:rosea.grammostola@__gmail.com mailto:rosea.grammost...@gmail.com mailto:rosea.grammostola@ mailto:rosea.grammostola@__gm__ail.com http://gmail.com mailto:rosea.grammostola@__gmail.com mailto:rosea.grammost...@gmail.com wrote: On 03/24/2012 11:09 PM, Fons Adriaensen wrote: 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). 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 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 Iirc it was just an idea to do make that. It doesn't exist yet. An overview would be good imo. It would be even better if such a matrix could help in making a decision for the best SM API to support, at the moment. As a user who wants to use session API X, I don't have much benefits if applications supports session API Y. Unless I decide to use Ladish, personally that wouldn't be my choice though. 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 ? A matrix is nice for a quick overview, but for such a decision you need more in depth information and argumentation. A matrix could only function as a tool to help with the decision. true, but currently we dont have any overview at all any tool is better than no tool, right ? We use a very old tool: dialogue, discussion and argumentation. :) Another one: try out and find the pros and cons yourself Sharing of user and developer experiences Then there is the NSM API documentation and the JackSession documentation. But if you want to make such a matrix, go ahead, but it might be harder to put it in a matrix then it looks at first sight. \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On 03/29/2012 04:22 PM, Emanuel Rumpf wrote: Am 29. März 2012 13:16 schrieb thijs van severen IMHO making such a matrix is the only good way to make a decisions of any kind 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. I think a conceptual analyses is also needed on forehand, without the SM being complete. You could think of questions like: * is it (in theory) possible to use it crossplatform, * is it (in theory) possible to use it without X, * is it (in theory) possible to use it via the network * etc You don't want to support an API which can't run (in theory) crossplatform. You have some standards a SM should be able to do, like there is for JACK and all other kinds of stuff. But I agree, user experience is important too. So Thijs, Louigi, ... , did you try it already? What are your experiences? Thanks for your opinion. I tend to agree with you and Renato: rather not make it too complicated, but usable and reliable. +1 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On 03/26/2012 10:47 PM, rosea.grammostola wrote: On 03/26/2012 10:32 PM, Emanuel Rumpf wrote: I've been able now to launch the NON session-manager. - by writing an own simple build-script. ( is my system borked ? or just cmake ?) cmake, iirc it's just ./configure, make, make install I have to say, I'm counting me as a fan of J. Liles Software. Somehow I agree with his style, I would described as unbloated, but still pragmatic and effective. - - - In my opinion NSM is the best approach to session management so far and I'm encouraging every audio-app dev. to jump on this train ! It is non-intrusive, has the required functionality. All though I think I share your opinion here, I do realize that developers jumped on trains before... I can also imagine some frustration if you just added JS to your app and now this new train is coming by. That's why a close research on the characteristics, advantages and disadvantages is important imo. If at the end NSM it as good as it looks, we can jump on that train together without hesitation. We have to be sure somehow that this is a train which takes us where we want to be (blue water with a yellow beach), in such a way that we don't need another train afterwards to be able to reach our destination. - - - There some minor things, I'd like to see: - sessions should have an option to optionally restore window-position and -size of client apps too (would this work for workspaces as well, possibly xinerama ?) I use fluxbox for this. - tools as nsmd, jackpatch, osc_send should show a help message, when started from command line. - the session-manager should have an additional help button, showing a window describing the possible actions (how to duplicate a session, work with templates) - just like non-seq has a window for key-strokes. - in the session-man. there should be a hint where the data is stored. I'd like to always know where it is. Questions remaining: - where would audio apps store large (audio) files ? a custom path ? - appart from large files (audio), all configuration should go to the instances session folder - right ? 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On 03/28/2012 10:43 PM, J. Liles wrote: On Wed, Mar 28, 2012 at 11:25 AM, rosea.grammostola rosea.grammost...@gmail.com 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? Pretty much the same way you do it with Ardour. Just make a tar.bz2 of the session directory (e.g. ~/NSM Sessions/Songs/The Song I Want To Share) and send it to your friend, they untar it in their session root, and NSM will find it. In the general case, this will work fine. Of course, just like with Ardour, whether the session actually loads and works properly depends on whether or not your friend as the same programs and plugins (or compatible versions of them) installed. Now if you later want to merge the two sessions, you're really on your own. In that case, making your session folder into a git repository would probably work better than just using tar. Non-DAW and Non-Mixer project data is textual and can be meaninfully managed by a line-based diff algorithm like GITs, but MIDI data (Non-Sequencer)--not so much. 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On 03/28/2012 10:20 PM, rosea.grammostola wrote: On 03/28/2012 10:43 PM, J. Liles wrote: On Wed, Mar 28, 2012 at 11:25 AM, rosea.grammostola rosea.grammost...@gmail.com 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? Pretty much the same way you do it with Ardour. Just make a tar.bz2 of the session directory (e.g. ~/NSM Sessions/Songs/The Song I Want To Share) and send it to your friend, they untar it in their session root, and NSM will find it. In the general case, this will work fine. Of course, just like with Ardour, whether the session actually loads and works properly depends on whether or not your friend as the same programs and plugins (or compatible versions of them) installed. Now if you later want to merge the two sessions, you're really on your own. In that case, making your session folder into a git repository would probably work better than just using tar. Non-DAW and Non-Mixer project data is textual and can be meaninfully managed by a line-based diff algorithm like GITs, but MIDI data (Non-Sequencer)--not so much. Nice. I've to find another question or user scenario then, And/ or developer scenario's of course. E.g. examples how hard and cumbersome it is to add NSM support to an application, especially with certain applications. The disadvantages of the API, the problems you get when you want to use it crossplatform, or without a graphical interface, etc. etc. 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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On 03/24/2012 11:09 PM, Fons Adriaensen wrote: On Sat, Mar 24, 2012 at 04:19:03PM +0100, rosea.grammostola wrote: More devs with an opinion? Fons, Torben, Paul, Emanual, ... ? I haven't used it so far (that is just a matter of limited time and priorities). But on reading the available docs my first impression is that there is some serious thinking behind this. There are quite a few features/choices that I do like/agree with. 1. The use of OSC, defining only the messages and leaving the actual implementation of the OSC interfaces to the application author. This instead of the all too common practice of imposing the use of some library that would integrate badly with the existing framework of an app, duplicate existing functionality or be in conflict with it, or pull in unwanted dependencies. 2. The use of jackpatch to manage jack connections instead of interfering with Jack itself. It's not clear from the specs, but if this means that NSM will (or can be told to) leave Jack completely alone I'll like it even more. 3. Clearly defining the way an app should behave w.r.t. its File menu entries (when managed). This is quite intrusive to existing clients, but it is IMHO absolutley essential. Kudos to the designer(s) for the having the courage to do this instead of allowing application developers to take the 'least effort' way (which would of course be better marketing, but invite later misery). At this point we can at least conclude that the people who have spoken out about session management and 'the modular approach' in the last couple of years and/or are involved in thinking about or building a session manager solution, agree more or less about the fact that NSM has a nice design and is probably useful in the different workflows. These people are, to name a few, Fons, Liles (author of NON) and Nedko (all though he thinks a session manager should do even more, that's what Ladish does. But ladish supports also JS and NSM (soon)). The JS developers didn't speak out clearly yet. What could be an advantage of JS, is that it has JACK as only dependency and is integrated in JACK. Others however, have pointed out that not depending on JACK is a big plus for them or even a demand. It gives more possibilities to have other apps in the session. As mentioned before, NSM seems to have some advantages JS doesn't have and lacks some disadvantages Ladish have (you need jackdbus). To call NSM a good compromise wouldn't give NSM the credits it deserves, but on the other hand, NSM could probably be a widely supported session API within the LAD/LAU community. This would be a unique situation. It's to early to settle down our conclusions though. It would be nice if more developers dive into it, study the API, study the practical implications, use NSM and probably even try to build a patch for it into their program, so we could have a better overview about how developers think about NSM. It could be that developers prefer a other session API then NSM. Maybe it's good to give your arguments. It's good to have disagreements and unity has it's disadvantages, but for an session API it's also good have agreements. Actually, you need enough of them to be successful as a Linuxaudio session API... Best regards, \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On 03/26/2012 05:51 PM, Louigi Verona wrote: Hey! I would like to ask. I did see a demonstration and it looks really nice. However, am I right in understanding that currently only several apps are really supported? And if this is true - is there an option of adding support for more apps? The API is explained on this website: http://non.tuxfamily.org/nsm/API.html Developers can build patches for their software to support NSM, as they can do for JS and Ladish. At the moment only non-daw, non-seq, non-mixer and yoshimi (patch available). Atm their are more applications with JS support (Ladish supports ladi, JS and NSM): http://tangostudio.tuxfamily.org/en/packages/unstable But the development of JackSession API has more or less stopped because of the fact that Torben has no time for Linuxaudio atm. Also it's not realistic to expect many efforts from Paul in this area. Moreover, NSM seems to have features JS lacks, but which could be a plus when it comes to workflow (stop session, copy session, more easy to add apps without session support into the session, possible to add apps without JACK support to the session). Also some people (Fons, Liles, Nedko) think that JS has it's limitations and therefore they don't support it (Fons, Liles). NSM could gain wider support probably. At first sight, NSM looks to me more promising then JS does, e.g. it has more chance to become really useful and to get broad support in the community (from the 'modular diehards'). But this is just a personal feeling/ thought. If this is really the case, depends on the view of the LAD community. \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On 03/26/2012 06:21 PM, Louigi Verona wrote: more easy to add apps without session support into the session How is that done? On Mon, Mar 26, 2012 at 7:15 PM, rosea.grammostola rosea.grammost...@gmail.com mailto:rosea.grammost...@gmail.com wrote: On 03/26/2012 05:51 PM, Louigi Verona wrote: Hey! I would like to ask. I did see a demonstration and it looks really nice. However, am I right in understanding that currently only several apps are really supported? And if this is true - is there an option of adding support for more apps? The API is explained on this website: http://non.tuxfamily.org/nsm/__API.html http://non.tuxfamily.org/nsm/API.html Developers can build patches for their software to support NSM, as they can do for JS and Ladish. At the moment only non-daw, non-seq, non-mixer and yoshimi (patch available). Atm their are more applications with JS support (Ladish supports ladi, JS and NSM): http://tangostudio.tuxfamily.__org/en/packages/unstable http://tangostudio.tuxfamily.org/en/packages/unstable But the development of JackSession API has more or less stopped because of the fact that Torben has no time for Linuxaudio atm. Also it's not realistic to expect many efforts from Paul in this area. Moreover, NSM seems to have features JS lacks, but which could be a plus when it comes to workflow (stop session, copy session, more easy to add apps without session support into the session, possible to add apps without JACK support to the session). Also some people (Fons, Liles, Nedko) think that JS has it's limitations and therefore they don't support it (Fons, Liles). NSM could gain wider support probably. At first sight, NSM looks to me more promising then JS does, e.g. it has more chance to become really useful and to get broad support in the community (from the 'modular diehards'). But this is just a personal feeling/ thought. If this is really the case, depends on the view of the LAD community. \r On 03/26/2012 06:21 PM, Louigi Verona wrote: more easy to add apps without session support into the session How is that done? You are able to start the client via the Non Session Manager GUI. If you need to add arguments to the client, you can do this via a script using the exec command. Liles is going to write a proxy app to make this more easy. With the client jackpatch you can make the connections. You have to manually save the clients who doesn't support NSM in this situation. Iirc this is also possible with JackSession, but it's not implemented in Qjackctl and I'm not sure how this works at the end. At least in NSM it seems to be more easy, with a nicer workflow. hth \r Regards, \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On 03/26/2012 10:32 PM, Emanuel Rumpf wrote:
I've been able now to launch the NON session-manager.
- by writing an own simple build-script.
( is my system borked ? or just cmake ?)
cmake, iirc it's just ./configure, make, make install
I have to say, I'm counting me as a fan of J. Liles Software.
Somehow I agree with his style,
I would described as unbloated, but still pragmatic and effective.
- - -
In my opinion NSM is the best approach to session management
so far and I'm encouraging every audio-app dev. to jump on this train !
It is non-intrusive, has the required functionality.
All though I think I share your opinion here, I do realize that
developers jumped on trains before... I can also imagine some
frustration if you just added JS to your app and now this new train is
coming by. That's why a close research on the characteristics,
advantages and disadvantages is important imo. If at the end NSM it as
good as it looks, we can jump on that train together without hesitation.
We have to be sure somehow that this is a train which takes us where we
want to be (blue water with a yellow beach), in such a way that we don't
need another train afterwards to be able to reach our destination.
- - -
There some minor things, I'd like to see:
- sessions should have an option to optionally restore window-position
and -size of client apps too (would this work for workspaces as well,
possibly xinerama ?)
I use fluxbox for this.
- tools as nsmd, jackpatch, osc_send should show a help message,
when started from command line.
- the session-manager should have an additional help button, showing a
window describing the possible actions (how to duplicate a session,
work with templates) - just like non-seq has a window for key-strokes.
- in the session-man. there should be a hint where the data is stored.
I'd like to always know where it is.
Questions remaining:
- where would audio apps store large (audio) files ? a custom path ?
- appart from large files (audio), all configuration should go to the
instances session folder - right ?
- where is the integrated chat client ? ;)
Possible Bugs
- although jackpatch is loaded, some connections (jack-midi) are not
restored here,
switching from one to another session (while the jack-audio-connection
is being done)
Known bug, should be better in git ('next branch'??)
- switching from one session with yoshimi to one without it closes yoshi
however:
switching from a session with two non-seq instances to a session
with only one non-seq instance
doesn't close the second instance
Once this is bug-free,
this session-manager is a real enrichment to the audio community !
There's almost a fun-factor using it. I'm going to spend my time
switching sessions soon. :)
I do share your optimism, but I don't want to celebrate to early this
time...
Regards,
\r
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On 03/22/2012 04:10 PM, David Robillard wrote: On Thu, 2012-03-22 at 11:55 +0100, rosea.grammostola wrote: Hi, I wonder what the LAD community thinks about Non Session Manager http://non.tuxfamily.org/nsm/API.html http://non.tuxfamily.org/nsm http://www.youtube.com/watch?v=ui-gC_ZMeGM http://youtu.be/xzspJXbEoc0 From a user POV I must say that it works very smooth at first sight. I haven't actually tried it yet, but took a peek. From the developer POV, the implementation of the daemon about 2000 lines of C or so, and it only depends on a standard protocol (OSC) with several implementations. I have no idea how well it works, or what I think of the details, but that wins it major points in my book. It is an appropriate size for the task at hand and doesn't ram dependencies down implementer's throats. -dr Thanks David. More devs with an opinion? Fons, Torben, Paul, Emanual, ... ? \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On 03/22/2012 12:59 PM, thijs van severen wrote: 2012/3/22 rosea.grammostola rosea.grammost...@gmail.com mailto:rosea.grammost...@gmail.com Hi, I wonder what the LAD community thinks about Non Session Manager http://non.tuxfamily.org/nsm/__API.html http://non.tuxfamily.org/nsm/API.html http://non.tuxfamily.org/nsm http://www.youtube.com/watch?__v=ui-gC_ZMeGM http://www.youtube.com/watch?v=ui-gC_ZMeGM http://youtu.be/xzspJXbEoc0 From a user POV I must say that it works very smooth at first sight. It's easy to use and one of the strong points seems to be the flexibility, e.g. the ability to copy and change existing sessions, run multiple sessions (also via network). But I cannot comment on the technical goods and bads of the API and how easy it will be to implement this in a Jackaudio application. It seems to use OSC messages and depends only on liblo. Thanks in advance, \r MHO: having a good universal session manager would be a dream come true, but so far i have not been able to find one that does what i would like it to do : - start a couple of apps - wire them together - add some more apps - save everything - done This is what Session managers do, NSM, JackSession and Ladish. Try it. for me it is rather annoying that i have to predefine a session (as is the case with most session managers). i just would like to open apps, use them, connect them, without having to think about 'the session', let alone 'predefine' it jacksession offers some of this, but not all apps support jacksession non session manager has some interesting features too (like over-the-network sessions) I don't think this is true. You can start apps just as you like and save the session. In NSM you do this in the GUI, but it's very easy to remove a client in a session or add one, so no need to predefine anything. A problem are clients without support for the session format. At least in NSM it's easy to start any application nevertheless (the author is also thinking about writing a wrapper for non supported apps). At least NSM acts like a script starting clients and restore the JACK connections (via client jackpatch). So people who prefer scripts and aj-snapshot, will find the same benefits in NSM if the author has added the wrapper (to be able to add arguments to a starting client). This is also more or less possible in JackSession, all though saving and quiting the session works more cumbersome in Qjackctl compared to NSM in my opinion. There is a possibility to start apps without JS support, but that's not implemented in Qjackctl yet, so atm a practical disadvantage of JS. There is a non official supported wrapper for JackSession though, js_wrap. We all know that session management is hard, but if we can live with more or less one standard it would be nice. JackSession seems to be an option, but if I understand the situation well, it seems that Paul Davis rather sees LV2 rise, he doesn't really believe in Session Management, so he is probably not very motivated to help it rise. Torben wrote JackSession, but he doesn't have time for Linuxaudio atm, so it might be fair to question the chances for survival here. I don't say that JackSession could not survive, but it needs support and development. If the community can agree on a format (NSM for example) which is supported better, then that might be a better option. Apart from the politics it's just interesting to discuss the NSM API here. Best, \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On 03/22/2012 02:52 PM, Harry van Haaren wrote: On Thu, Mar 22, 2012 at 12:33 PM, rosea.grammostola rosea.grammost...@gmail.com mailto:rosea.grammost...@gmail.com wrote: JackSession seems to be an option 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. And what if there is no real objection towards NSM from within the community and what if the JS devs tell you that they have no time or motivation to really develop or stimulate development of JackSession? Isn't is possible then that the community more or less decides that one option is better then the other? Or is someone else willing to maintain JackSession from now on? NSM doesn't depend on JACK, how bad is that really? At least one benefit seems to be that apps like non-mixer are also supported now. And even apps without JACK support, (all though I can't find a situation at this moment in time where this can be useful). In my view all depends on the vision of the LAD community. I just tried NSM yesterday, but what if it's the best solution overall? That's possible right, that someone suddenly comes up with the best solution so far. If NSM is that best solution, we might go for it. Otherwise we have to think about keeping JackSession alive. Harry, maybe it's good to give NSM a shot and/ or to comment on the API. \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Non Session Management
On 03/22/2012 05:52 PM, Emanuel Rumpf wrote: Am 22. März 2012 11:55 schrieb rosea.grammostolarosea.grammost...@gmail.com: I wonder what the LAD community thinks about Non Session Manager I would like to try it, but I can't build the DAW and NSM . It doesn't link and causes lots of undefined reference messages. Is the build script is broken ? My FLTK installation seems ok. _ I didn't have problems building it a few days ago. You probably could email the author or jump in on #lad ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Petri-Foo - a new fork of Specimen
On 02/06/2011 10:33 PM, James Morris wrote: I've created a sourceforge project page for Petri-Foo. Anyone interested should subscribe to the petri-foo-devel list for development and users alike here: https://lists.sourceforge.net/lists/listinfo/petri-foo-devel Cheers, James. On 4 February 2011 11:18, James Morrisjwm.art@gmail.com wrote: Hi, I've forked Specimen primarily to provide frequency Modulation of the LFOs and to make all the LFOs and ADSRs independent so that there is no longer a single dedicated ADSR and a single dedicated LFO for ie pitch modulation, but two 'inputs' for pitch modulation for which the choice of all ADSRs and all LFOs is available. Please read the README for more information: https://github.com/jwm-art-net/Petri-Foo#readme The current state of Petri-Foo is that the LFOs and ADSRs have been made independant and are, AFAICT, working as should. The GUI is not yet up to date, but changes have been made enough to get a basic idea of what's going on. Please do read the README before commenting. I've tried to do things properly! I'm only human and only a hobbyist coder. Cheers, Hi, Does your fork include the JackSession patch to enable jacksession support? Would be nice. Should be in Specimen svn http://trac.jackaudio.org/wiki/WalkThrough/User/jack_session \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] LAC: Anyone driving to Dublin after the Linux Sound Night(s)?
Hi, I might be staying in Dublin during the LAC. The last train on friday and saturday is leaving on 23:10. The concerts might not be ended at that time. Is there someone who is driving from Maynooth to Dublin after the sound night and who can take someone with him? Regards, \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] On the last eve of the year
On 12/31/2010 05:44 PM, Dave Phillips wrote: Jens M Andreasen wrote: The Little Match Girl http://mx44.linux.dk/~jens/unpublished/mtchgirl.mp3 beautiful. \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [OT] Richard Stallman warns against ChromeOS
On 12/14/2010 09:28 PM, gene heskett wrote: On Tuesday, December 14, 2010 03:27:37 pm Victor Lazzarini did opine: Stallman hitting the mainstream news: http://www.guardian.co.uk/technology/blog/2010/dec/14/chrome-os-richard -stallman-warning He's right. +1 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] General question: Components of Music Software
On Tue, 2010-04-27 at 09:52 +0200, Jeremy wrote: On 04/26/2010 09:08 PM, Louigi Verona wrote: Jorn! Thanks, very informative answer. What can you say about stuff like this: 1. vocoder 2. grnulizer 3. slicer (when a file is sliced into pieces) Hello Louigi, Smasher: http://smasher.sourceforge.net Or a good ole tracker like MilkyTracker for even more finer grained control. 4. beat matching That's still missing, a good FLOSS beat matching app or library. At least, I haven't come across one yet. Is beat matching different then beat slicing? aubiocut http://tardigrade-inc.com/index.php/En/Software rhythm ferret in Ardour (or what is it's name)? Freecycle SuperCollider? \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] distros migrating to JACK2?
On Sat, 2010-04-17 at 12:10 +0200, Stéphane LETZ wrote: At Grame, we started working on JACK (jack1 at that time) in 2003 and our first commitment was to port the C code base on OSX. Even if the result was working, we rapidly felt that the C code base was not flexible enough to evolve in the direction we wanted to explore: multi-platforms support, SMP and glitch-free connections (among other ideas we had...) . Around 2004-2005 we had a new C++ based code base that was first developed on OSX, later ported in Linux (2005), on Windows (summer 2006) and Solaris (summer 2008 as a result of funding coming from RTL french radio). In 2004 we also found the way to better integrate JACK in the CoreAudio architecture on OSX (the JackRouter JACK/CoreAudio bridge) that allowed any CoreAudio application to become a JACK client, thus participating in the success we had on OSX with the JackOSX package. I think the about 3 years ago, the JACK mini-summit in Berlin Paul told about, was actually during LAC 2008 in Kohn. It was my impression that most of the JACK community was interested to see jackdmp (renamed jack2 at that moment) become the future of JACK, and late 2008 and 2009 was an intense period of work to reach this goal. Nedko (mostly but some other) did a huge job of improving the build system, implement the so-called JACK Control API (or at least the server side of it) and helped in other areas. The D-Bus based server control code (Nedko) was also integrated at that time. In spring 2009 started this D-Bus war and after endless discussion with people with strong opinions (Fons, Nedko...) it appeared that no agreement could be found. The best that we could achieve (in my view) was to clearly define the JACK Control API as the frontier between the external world that wants to control the JACK server, and the server code itself, and report all more sophisticated control mechanism outside. At about the same time, some developers (Torben, Paul ...) started to rebirth the jack1 codebase, and it appeared more and more clear that the jack2 become the official code base idea start to become a vanishing goal. I must say that I still don't have a clear understanding of why this happened. I still don't understand the sentence Like Torben, there are some design decisions there that I have questions about. and I think explaining it in more details would really help. It's pretty odd that you guys didn't discuss this clearly with each other. It seems that people have an opinion about something, but only share this with people who have the same opinion and not with the one who himself or his code is subject of 'critique'. This is bad communication and bad team management. The fact that jack1 and jack2 are almost indistinguishable in everyday use is quite satisfactory, but at the same time the subtle difference that stay continue to cause some endless comments from users about the real advantages of each of the two implementations. I still see reports from more xruns here or a bit less CPU use there, but with no real data and clear step by step way to reproduce issues that would help to fix remaining bugs in jack2 codebase (for example jack2 still probably has issue with multi-cards support compared to jack1, but AFAICS this is in ALSA backend, and I cannot progress on that without the help of people with multi-cards and knowledge in ALSA backend code). Concerning session management added in JACK codebase, I did not followed the discussion in details. I said to Paul in a private mail that I though it was not a good idea (but maybe I am completely wrong...) but I would certainly not oppose to a implementation for jack2. I remember someone volunteered to work on that ?? I have to say that I become quite tired of all that mess, since I don't see any clear way to solve the situation. After about 5 years of real commitment in JACK project, I decided to move back a bit and work on some other stuff. I still try to follow bug reports and jack1 changes, release a package from time to time and maintain JackOSX project. I still think some interesting ideas (like the pipelining mode that currently stay in a jack2 branch...) are of interest (especially since we now see with those 4 cores/threads model in new laptops...) and should be pushed in mainline. It would be good if an '(mini) JACK Conference' will be organized, where JACK developers can speak each other face to face, code to code. And share future vision, coding vision etc. IRC and mailinglists are great, but not always the good method for communication. Regards, \r ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] distros migrating to JACK2?
On Sun, 2010-04-18 at 08:31 -0400, Paul Davis wrote: On Sun, Apr 18, 2010 at 5:16 AM, rosea.grammostola rosea.grammost...@gmail.com wrote: It's pretty odd that you guys didn't discuss this clearly with each other. It seems that people have an opinion about something, but only share this with people who have the same opinion and not with the one who himself or his code is subject of 'critique'. This is bad communication and bad team management. oh god. you clearly don't understand ANYTHING about how open source development works. there was constant discussion about all of this. But Stephane doesn't own JACK, I don't own JACK, Torben doesn't own JACK, Jack O'Quinn doesn't own JACK. When someone works on their own implementation of JACK, they are free to make their own decisions about how things are done. Maybe their ideas will be better (or worse, or about the same) as any existing implementation, and because of this, its important to allow them to take shape as they see fit. Clearly, providing useful feedback and ideas is great, but there's no reason for any committees or meetings to decide how a different implementation is going to work. In this particular case, Jack2 started out (as Stephane has described) as a sort of experiment - how would SMP support work, could we do click-free graph changes, would a C++ implementation be easier to manage, etc. etc. In that context, its not appropriate for anyone who's not actually working on it to be trying to make decisions about internal design. Lots of people, including myself, had input into the design and evolution of Jack2. Pretending otherwise is ridiculous. Jack1, Jack2 (and even the not-quite-born tschak) all implement 99.83% of the same API. Beyond that, how they work internally is the business of their implementors and maintainers. If someone has an opinion about it, they are free to take it up with the implementors and maintainers. If they feel strongly enough about it, and they don't feel that the implementors/maintainers are doing things in the right way, they can fork or reimplement (this clearly doesn't happen much). This could all be true, but that's not the point I was talking about. JACK2 was planned as successor of JACK1. But at some point that changed, that's all ok, not the point here. But isn't it odd that this isn't clearly communicated with the JACK2 maintainer, why this is happened? That was raising questions here about the communication within the (highly appreciated) JACK project. quote=Stephane I must say that I still don't have a clear understanding of why this happened. I still don't understand the sentence Like Torben, there are some design decisions there that I have questions about. and I think explaining it in more details would really help. Regards, \r It would be good if an '(mini) JACK Conference' will be organized, where JACK developers can speak each other face to face, code to code. And share future vision, coding vision etc. IRC and mailinglists are great, but not always the good method for communication. Traditionally, this would be done at the Linux Audio Conference, which I will, alas, be unable to attend this year. That doesn't stop other people from meeting on these issues, but my impression is that we have all become somewhat tired of struggling with the situation and instead have been trying to find ways to allow the status quo to continue, but better. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
