Re: [LAD] LADI

Modular environment is great, but integrated environment seems to be more effective. I mean, imho it is not a matter of preference and I am not saying no work should be done on session management. I am just saying that so far my observations show me that integrated environment has too many benefits over modular environment. I am relatively new to linux audio, so I would be grateful if you would explain to me the benefits of modular environment. So far I've not been able to see any special benefits of such an environment. I mean, it's curious, but it also means lots of open windows, it means the project being dependent on many-many apps. Somehow to me it means working on the problem from the outside. All the inter-application management seems to be a difficult problematic and even in the long run is doomed to have many problems due to many apps involved. A dev releases new version of his app that has a bug and session handler cannot connect it - and boom! But I also have a suggestion. Is it possible to create an integrated environment based on modules? That is, an app which would have "plugins", but not plugins in a sense like effects and synths only, but plugins as elements of the sequencer itself, like piano roll, song editor, such stuff. A person opens this app and starts adding elements he needs to it. For a particular project he might not need a piano roll, he might need only audio track arranger, for another projects he takes an audio track arranger and also adds a piano roll. Modules of such an app could be very different, like a loop player like Kluppe, etc - all the apps linux audio has to this day but remade as modules to an integrated sequencer. What do you think? Louigi Verona. On Sun, Dec 20, 2009 at 4:18 AM, Patrick Shirkey <pshirkey(a)boosthardware.com > > On 12/20/2009 11:48 AM, Louigi Verona wrote: > > > So, as a musician, I think linux audio developers have to focus on > > 1. integrated audio environment > 2. sotware synthesizers/effects (LV2) > > > > > I prefer to work with a modular environment and want to see session > management working properly. I would be very disappointed if no further work > was done on session management. > > I am looking forward to the progress that will be made over the next couple > of years on that front. > > > > > > > Patrick Shirkey > Boost Hardware Ltd > > > > > > > > > LMMS is an integrated environment and having Zyn inside it is great. LMMS > is very promising. > But what isn't there are plugins and synthesizers. As an ambient composer I > simply lack the tools > I need, > > Hope any of this was useful. > > Louigi Verona. > > > > > > > On Sun, Dec 20, 2009 at 1:19 AM, <fons(a)kokkinizita.net> >> On Sat, Dec 19, 2009 at 09:15:22PM +0100, rosea grammostola wrote: >> >> > 1) The 'one app with plugins' group. People who are focusing on one big >> > app, extended by plugins (Ardour, Qtractor, LV2/DSSI). This group >> > doesn't have much interest in a session handler. >> >> And quite probably the authors of these apps are not very >> motivated to make them compatible with session handlers. >> >> > 2) The people who likes to work with different, small Jack applications >> > (ams, aeolus, epichord etc.). These people are interested in a session >> > handler. But they think dbus is the wrong approach, it is to limited for >> > them, or it is not the right thing for the Linux platform in their >> opinion. >> >> 'Like to work' may not be the correct interpretation. See (4) >> >> > 3) Group 3 is the same as group 2, BUT they have chosen dbus as >> > solution. It's the LADI group. >> >> 4. And there's group 4, or maybe that group is just me. >> If there are others I'd like to know. For group 4: >> >> * Sessions are multi-host since there is no other way. >> In most cases all but one of the machines involved will >> be headless, and whatever is supposed to happen there >> is by definition remote controlled instead of being >> launched from a local desktop. >> >> * There are no usable 'single app with plugins' solutions >> since none of these comes close to what would be required, >> in particular w.r.t. the multi-host situation, and also >> because all of these apps silently assume a human user >> watching them and being able to take corrective action >> if necessary. Anything that could pop up an error dialog >> and refuse to proceed until someone reacts is completely >> useless in such systems. >> >> * Any interaction between components of such a system is >> supposed to use networked communication from the start. >> Dual-layer solutions based on some local IPC system plus >> some additional layer that would connect them via a network >> are just an unnecessary complication, and probably one that >> would not provide the right semantics, since the design would >> be based on the single host assumption in blissfull ignorance >> of what it takes to make things work together via a network. >> >> * Given the potential complexity of a networked system, loading >> a 'session' would in general not mean a complete teardown and >> buildup of all apps and their connections, but could just mean >> loading a different configuration in a single app, without even >> any others being aware of this. >> >> People using such systems are *very* motivated to create >> some form session handling, since controlling this sort of >> thing manually is a real PITA, in particular if you have >> to do it a hundred times a day, or if you have to provide >> an interface usable by non-experts. Which is why I have >> been working on this. And given the quite hostile reactions >> shown in recent threads, and the probably minute potential >> user base, the chances that the results will be made public >> are rather small. >> >> Ciao, >> >> -- >> FA >> >> _______________________________________________ >> Linux-audio-dev mailing list >> Linux-audio-dev(a)lists.linuxaudio.org >> http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev >> > > > _______________________________________________ > Linux-audio-dev mailing listLinux-audio-dev@lists.linuxaudio.orghttp://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev > > > _______________________________________________ > Linux-audio-dev mailing list > Linux-audio-dev(a)lists.linuxaudio.org > http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev > >