Good. Can you explain me why you prefer LMMS above Qtractor atm?Louigi Verona wrote:Yeah, I am very active with giving feedback on QTractor too and also did some feedback for NonMixer.
In what way modular approach is limiting
Moderators: MattKingUSA, khz
Re: In what way modular approach is limiting
- Louigi Verona
- Established Member
- Posts: 402
- Joined: Mon Aug 24, 2009 8:56 am
- Been thanked: 1 time
Re: In what way modular approach is limiting
Because with Qtractor I cannot go back to the beginning of the tune and change something if I want - I have to actually resetup a synth I used, remember what preset I used, load it up and possibly even perform it again.
In fact, I did make a nice tune with QTractor, using Bristol synths. When in the middle of a tune I decided to change a chord in the middle, I understood that it is not possible without re-recording everything. The way the tune was done - it was simply not an option.
Adding to that the fact that Bristol synth take lots of CPU and get kicked out of JACK regularly, I cannot keep several of them open.
Do you understand what I mean?
In fact, I did make a nice tune with QTractor, using Bristol synths. When in the middle of a tune I decided to change a chord in the middle, I understood that it is not possible without re-recording everything. The way the tune was done - it was simply not an option.
Adding to that the fact that Bristol synth take lots of CPU and get kicked out of JACK regularly, I cannot keep several of them open.
Do you understand what I mean?
Re: In what way modular approach is limiting
I understand it. I did an test session with qtractor and decided to do it with Ladish, cause you don't have to restart the external synths (zynaddsubfx and phasex in my case) manually again. Then another problem is indeed the presets you use in the synth. Luckily enough most of the synths are able to save presets. In Ladish you can start an app with a certain project file or patch atm like you would do in the terminal.Louigi Verona wrote:Because with Qtractor I cannot go back to the beginning of the tune and change something if I want - I have to actually resetup a synth I used, remember what preset I used, load it up and possibly even perform it again.
In fact, I did make a nice tune with QTractor, using Bristol synths. When in the middle of a tune I decided to change a chord in the middle, I understood that it is not possible without re-recording everything. The way the tune was done - it was simply not an option.
Adding to that the fact that Bristol synth take lots of CPU and get kicked out of JACK regularly, I cannot keep several of them open.
Do you understand what I mean?
Btw is Bristol a good synth?
- Louigi Verona
- Established Member
- Posts: 402
- Joined: Mon Aug 24, 2009 8:56 am
- Been thanked: 1 time
Re: In what way modular approach is limiting
Bristol project is a great project which is worth working with. Also, the more people use it, the more valuable feedback the dev behind it gets. I suggest you try compiling the latest version.
Re: In what way modular approach is limiting
I found out how LMMS is working with midi and the samples in an internal sampler. It seems that you can do this with the modular approach with samplers as Specimen, Linuxsampler (gigedit) and Swami (soundfont). Gig files (linuxsampler) and soundfonts (fluidsynth dssi) can be used as plugins in qtractor for example.
Also Hydrogen is an option. And maybe I forgot one?.....
http://apps.linuxaudio.org/apps/all/specimen
(here someone shows how to work with it http://www.youtube.com/pneumanlsd )
http://download.linuxsampler.org/doc/gi ... start.html
http://swami.resonance.org/trac
http://briansbedroom.blogspot.com/2008/ ... it_21.html
Session handlers are on its way (Ladish and Torbens minimal session manager)
And also automation for midi stuff (qtractor, ardour and I hope non-sequencer will add some functionality)
edit: this seems also interesting in this realm: http://tardigrade-inc.com/index.php/En/Tapeutape
Also Hydrogen is an option. And maybe I forgot one?.....
http://apps.linuxaudio.org/apps/all/specimen
(here someone shows how to work with it http://www.youtube.com/pneumanlsd )
http://download.linuxsampler.org/doc/gi ... start.html
http://swami.resonance.org/trac
http://briansbedroom.blogspot.com/2008/ ... it_21.html
Session handlers are on its way (Ladish and Torbens minimal session manager)
And also automation for midi stuff (qtractor, ardour and I hope non-sequencer will add some functionality)
edit: this seems also interesting in this realm: http://tardigrade-inc.com/index.php/En/Tapeutape
Last edited by studio32 on Mon Mar 29, 2010 11:00 am, edited 1 time in total.
- Louigi Verona
- Established Member
- Posts: 402
- Joined: Mon Aug 24, 2009 8:56 am
- Been thanked: 1 time
Re: In what way modular approach is limiting
I agree that in theory modular approach can be uber-cool. In fact, with all the tools in place, there might be not a big difference between loading a plugin in IME or opening a synth in modular environment.
Thing is, we do not live in a perfect world and the biggest problem with the modular environment I see (as I wrote in the original post) is that in order to make modular good you have to rely on many different developers.
The more I read dev mailing lists, the more I see that it can be a problem. Different devs not only have different opinions, they actually act on them and deliver apps which are not compatible or which use different standards. For instance, Non-DAW does not support LV2 and actually they do not even plan it. They might have very good reasons for it, but in the end it means that one app supports this and one supports that. And since there is no commercial interest to support unification of standards, it simply does not happen.
I will prepare an article on modular approach and on a DAW in general and outline common usability/functionality problems of audio linux design - my opinion. It will be sort of another side of things.
Thing is, we do not live in a perfect world and the biggest problem with the modular environment I see (as I wrote in the original post) is that in order to make modular good you have to rely on many different developers.
The more I read dev mailing lists, the more I see that it can be a problem. Different devs not only have different opinions, they actually act on them and deliver apps which are not compatible or which use different standards. For instance, Non-DAW does not support LV2 and actually they do not even plan it. They might have very good reasons for it, but in the end it means that one app supports this and one supports that. And since there is no commercial interest to support unification of standards, it simply does not happen.
I will prepare an article on modular approach and on a DAW in general and outline common usability/functionality problems of audio linux design - my opinion. It will be sort of another side of things.
Re: In what way modular approach is limiting
It is a question whether it is better to rely on one or a few developers then on many... What if they stop, what if they don't support something?Louigi Verona wrote: Thing is, we do not live in a perfect world and the biggest problem with the modular environment I see (as I wrote in the original post) is that in order to make modular good you have to rely on many different developers.
Non-daw doesn't support plugins, non-mixer does. And I think the chance is pretty big that an developer (outside the project) adds lv2 support to it. Btw it is pretty easy with non-daw and non-mixer to route the audio through an LV2 host.The more I read dev mailing lists, the more I see that it can be a problem. Different devs not only have different opinions, they actually act on them and deliver apps which are not compatible or which use different standards. For instance, Non-DAW does not support LV2 and actually they do not even plan it. They might have very good reasons for it, but in the end it means that one app supports this and one supports that. And since there is no commercial interest to support unification of standards, it simply does not happen.
Does LMMs support LV2 and DSSI?
edit: BTW it seems that you can control jack-rack LADSPA host with midi cc messages (right click on enable) to do automation with ladspa plugins.
- raboof
- Established Member
- Posts: 1855
- Joined: Tue Apr 08, 2008 11:58 am
- Location: Deventer, NL
- Has thanked: 50 times
- Been thanked: 74 times
- Contact:
Re: In what way modular approach is limiting
Again, I fail to see this as a "modular vs IME" issue. For IME's it actually seems worse: each IME only supports whatever it supports.Louigi Verona wrote:in the end it means that one app supports this and one supports that
At least a 'modular' app speaks some kind of standard, so it supports anything that also speaks that standard, instead of just whatever was hard-coded into that app...
- Louigi Verona
- Established Member
- Posts: 402
- Joined: Mon Aug 24, 2009 8:56 am
- Been thanked: 1 time
Re: In what way modular approach is limiting
I am not sure. I don't think they support LV2.
What you say about many devs is true, given enough time. Basically, I am quite optimistic about modular approach as it is.
As for the IME vs modular, this exact statement has nothing to do with IME vs modular, it is about modular itself, not modular vs whatever.
What you say about many devs is true, given enough time. Basically, I am quite optimistic about modular approach as it is.
As for the IME vs modular, this exact statement has nothing to do with IME vs modular, it is about modular itself, not modular vs whatever.
- raboof
- Established Member
- Posts: 1855
- Joined: Tue Apr 08, 2008 11:58 am
- Location: Deventer, NL
- Has thanked: 50 times
- Been thanked: 74 times
- Contact:
Re: In what way modular approach is limiting
Ok - no argument there then, the fact that various standards are implemented to a various degree by various apps (tee hee) is a limitation. There's not really any alternative though, except for sticking with old standards and not inventing anything new anymore - and that's not really an option either.Louigi Verona wrote:this exact statement has nothing to do with IME vs modular, it is about modular itself, not modular vs whatever.
Re: In what way modular approach is limiting
Here it is, a standalone app for automation (not released yet afaik), but it seems there are more people with this idea...studio32 wrote:mmh I don't know Kluppe well... I 'll check it out. File a feature request there...Louigi Verona wrote:kluppe is the one I use most, but it does not have jack transport support. it might not be considered serious by some, but it is necessary for me.
Mmh automation..... Non-automation, like Non-mixer etc.???
http://img251.imageshack.us/img251/6827 ... shotjs.png
- autostatic
- Established Member
- Posts: 1994
- Joined: Wed Dec 09, 2009 5:26 pm
- Location: Beverwijk, The Netherlands
- Has thanked: 32 times
- Been thanked: 104 times
- Contact:
Re: In what way modular approach is limiting
Isn't that one of the apps Harry van Haaren is working on? I recall him showing it at LAC2010.studio32 wrote:Here it is, a standalone app for automation (not released yet afaik), but it seems there are more people with this idea...
http://img251.imageshack.us/img251/6827 ... shotjs.png
- Louigi Verona
- Established Member
- Posts: 402
- Joined: Mon Aug 24, 2009 8:56 am
- Been thanked: 1 time