LinuxMusicians

Louigi Verona wrote:If you want to record things, you go Pro Tools (Ardour).

I'm afraid I'm not exactly clear how JACK support won't help in this regard especially if I want to integrate synths into my recording.

Let me once more explain why JACK support in LMMS is low priority.

Making music in LMMS is same as making music in an editor like FL Studio - this is mostly non-real time work. ALSA midi is enough to record things into piano roll and then post edit them. This has nothing to do with connecting a synth to ardour and recording its output in real time. You program synths into piano rolls, programm drums, carefully draw out automations, put that all together into a song editor - and bam! You're done. I've worked in FL Studio for years, I've already made some cool tunes with LMMS without working under JACK, only under ALSA - I have experienced no difficulties. And even no dropouts.

Please, note again - and this is important - that so far all the guys that said that they do not understand why JACK is not important for LMMS are admitting they are using modular approach. Of course you cannot understand! Your workflow is wired differently. For you JACK is a must - without JACK your workflow is unthinkable. IME workflow without JACK works fine. It might be even better with JACK, but JACK is not necessary - and I am living proof of that.
But if inside LMMS you cannot route fx in the mixer from one track to the other - this, for instance, is much more important to the IME workflow than a little bit lower latency.

Do you understand?

This is why I wrote this article - to show that working in IME means absolutely different workflow and way of thinking.
And also that IME and modular need to live together in Linux. They are for different things and hardly compete with one another.

Louigi Verona wrote:... so far all the guys that said that they do not understand why JACK is not important for LMMS are admitting they are using modular approach. Of course you cannot understand!...

I understand perfectly well, Louigi, but JACK is more than an asset to modularity. As far as I'm concerned the problem with LMMS has nothing to do with workflow or compositional style. Performance issues could be eliminated with proper JACK support. AFAIK, there's no need for LMMS to announce itself publicly on the JACK graph, JACK can be utilized strictly in the capacity as a high-performance sound server.

JACK exists in a modular environment, it isn't necessarily stuck there. It doesn't have to be used in the same way as the devs for Ardour or QTractor are employing it.

LMMS offers JACK support now. It doesn't work well, so either they fix it or drop it. A bad implementation is worse than none at all.

The topic of workflow matters, but for me it isn't really a problematic aspect of LMMS. Performance is. If I understand you correctly you're far less concerned with performance during the composition stage. Is that correct or have I misunderstood you ?

Best,

dp

Interesting discussion.

Louigi Verona wrote:Being relatively new to Linux Audio, but not new to music, I perhaps might sound like one of those critics who start to speak about things they do not quite know about.
However, I still would like to take the liberty to discuss the limitations of modular approach, believing that my input can be useful simply because in these several months I've spent most of my free time working with GNU/Linux audio, learning, studying, trying out, keen on making GNU/Linux my musical station. So perhaps my dedication makes these 3-4 months a pretty vast experience.

Thanks for your input in this discussion.

However, I do not agree with people, who say that GNU/Linux should stick with modular approach and stream all energy in that direction.

Indeed, this opinion is very much dominating and the only IME - LMMS - in the world of Linux Audio is not getting much support from the core community.

It is not true that Linux audio is only focusing on the modular approach. The 'main app' Ardour for example, is working towards an IME approach. The same is true for LMMS, Qtractor (automation is on its way), Muse and Rosegarden. They might not be ready for it (Ardour) or are not good enough for your workflow maybe, but they are focusing on the IME approach and those apps are 'core apps' in the linux audio world. Also the new plugin formats LV2 (and DSSI) can be used for making effects and instruments.

Louigi Verona wrote:This is what Ardour is best at, this is what the whole workflow of many Linux applications is aimed at. The vast majority of midi DAWs, such as Muse, Rosegarden, QTractor, are aimed at producing electronic versions of acoustic music or additional arrangements around already recorded pieces - that is, use various external synthesizers to input notes. All the options, the way the workflow is shaped, is aimed at producing melodic music, similar to orchestral aimed Cakewalk in the early nineties.

Qtractor is made with electronic music in mind.
"Qtractor, an Audio/MIDI multi-track "bedroom" sequencer for the techno-boy and girl. "
http://www.rncbc.org/drupal/node/80

For an IME this is standard stuff. For modular approach setting all of this up for work is a serious task. And I've been working on the tune for several days in a row. Many times I had to go back to the beginning and change things - be it notes or parameters or automation. If that was done with modular approach, putting all that together would be a non-trivial task.
How would I go about it? Have audio samples in Ardour? But I need them in a piano roll so that I can easily play several notes in different pitches. Ardour does not have a piano roll. QTractor has a piano roll but it does not support having audio files as a midi source. In fact, I do not know of any program in Linux but LMMS that has that kind of functionality. Yet, it is nothing fancy. You have a sound effect and you want to play it in a different pitch. Of course, you can multiply the clip in Ardour and in copies of the clip change the pitch, that being a reference to the toothbrush example.

I would make the song in the midi sequencer, record it in Ardour and do the final mix e.g. automation and putting effects on it there.

I am not even mentioning that the amount of frustration to set things up even for an experienced musician is enough to kill any amount of inspiration. I remember I was doing a tune in QTractor. This tune used two Bristol synths and an organ. Simple enough, right? But setting it up each time was so long that many times I chose to not go through the process.

Qtractor and Bristol have both Ladish level 1 support:
http://wiki.linuxaudio.org/apps/all/ladish

2. Not guaranteeing standardization.
Thing is, even if we imagine we have a solid working session handler (which we do not), some app you are using might not yet support it or even never support it. So even if there is a session handler, nobody can guarantee all the apps will have it.

Ladish does support all apps at level 0 http://ladish.org/wiki/levels
Apps who aren't supporting level > 0 in Ladish can be started in Ladish via command line loading a certain project/ setting.

Moreover, the way programming works, especially in the free world, you rarely get an end product instantly. You first get alpha and beta versions and those go around for ages.
Relying on modular environment means relying on the developer of each app. It means that in order to make the system work perfectly, we need many-many developers to comply with the standard. In an IME there is no such thing. If the synth is ported into an IME, like Zyn into LMMS, everything is saved. You do not even have to save a preset, all your changes are simply saved within a project because in that case it is easier to implement a project setup.
So, the nature of the modular approach is such that it will never be perfect. It will always lack something - some useful app or a plugin which will happen to not support something - be it a session handler or a parameter control protocol or whatever needs support.

You can look to this the other way around. In the Open Source world they doesn't have the time and organization like you have in an company to make an IME applications which contain all you need. They have time to make one-task-one-tool applications, which can work perfect. It is harder to develop an IME application which does everything you need and doesn't have a lot of bugs. Also big chance that app will lack something.

Look at the modular approach. If app A lack an feature, there is app B who has that feature (most of the time), you can route it via JACK into A and you have the features you need. You say that the modular approach is always lacking. I say, an IME application is always lacking something, and then you're in trouble.
With the modular approach, using JACK (and Ladish) you can make your own DAW with all the features you need.

Conclusion.

Okay, so what exactly did I want to say with that?

1. I believe that GNU/Linux audio community has to be less rigid in the question of modular vs. IME approach and instead stop thinking in terms of "vs" at all. While modular approach is unique to Linux and certainly is perfect for certain tasks, no audio platform will be complete without a decent integrated music environment. This is not a question of being used to something or of luxurious convenience - it is a matter of being able or not being able to create certain types of music. In other words - IME is important. Yes, even for such a unique operating system as GNU/Linux.

As said before, it is absolutely not true that the community is only focusing on the modular approach right now. In fact it's more the other way around these days.

2. I am going even more detailed and claim, with a concrete audio example, that there are whole classes of music which are close to impossible to do with modular approach.

You should make more clear why making an orchestral piece, with all kind of different instruments and dynamics is so much different then making hardcore.

3. Finally, I show that due to the fact that modular environment is... well, modular, it by its nature relies on many different developers to work. That makes it vulnerable to a good app not supporting something or an app not being stable enough and thus falling out of the system. Thus, building a stable audio system becomes much more challenging since it relies on too many independent components.

That's exactly an reason to go for the modular approach imo. If app A fails, you can use App B. That's not possible in an non-modular IME app without JACK support.

It is also not true that on Linux audio, guys 'only' make rock or jazz music. Imo there is a lot of electronic music be made on Linux. Some use LMMS as there core app, some SuperCollider and the like, others take the modular road.

If you want to take the last way, then there are two interesting projects imo. First openoctave project (http://www.openoctave.org). Not that it is good for electronic music making especially (AFAIK), but as an example of how musicians with a certain focus, and programmers who like to contribute, come together and build (or better improve, adjust) the modular working environment they need. They are now reaching a state where they can make music on a professional way.

Another interesting project in this subject is Ladish (http://www.ladish.org) imo. It makes the modular approach more usable and friendly for musicians, also electronic musicians.

Why not gather some fellow electronic musicians with the same workflow, just like the openoctave team, and make the workflow you want possible on Linux. Choose apps you want in your workflow, help improve them and build sessions / studios / rooms (in ladish) and share them with each other.


When you say, "hey there is not Ableton Live app on Linux, which can do time-stretching and looping the same way as Ableton Live can do", you're right. But then you might ask your self whether it is reasonable to expect an Ableton Live on Linux made by the community (in a short time).

It is also true that Jack Transport could be improved, and that it isn't possible to loop with Jack Transport.
http://trac.jackaudio.org/wiki/TransportLimitations

It might also be true that there is no such tool as FL Studio on Linux, which helps you compose an song very quickly. All though LMMS (and Qtractor?) is striving to do so and you have Renoise of course (which is not GPL). (And you should try also non-sequencer, non-daw and non-mixer imho http://non.tuxfamily.org/)

My advise, keep giving feedback to the LMMS devs (and yes JACK adds something to that app, missing features for example ) experiment with apps you need for your workflow and use Ladish. Better, find musicians (ask them how they make their music on Linux) and developers with the same goals and develop your own perfect workflow on Linux as a group of electronic musicians.

There are a lot apps which might help you making electronic music the way you want. Think of LMMS, Qtractor, Ardour, Sooperlooper, Freewheeling, Non-Daw, Non-mixer, Non-Sequencer, Zynaddsubfx, PHASEX, Whysynth, PureData, Hydrogen, LV2rack, Supercollider, autotalent plugin etc.

Yeah it might be a pain some or even many times, like it was for the openoctave members when they started with Linux audio, but there are chances for sure, also for electronic music imho.

Hey guys!
Let me comment on some points.

If I understand you correctly you're far less concerned with performance during the composition stage. Is that correct or have I misunderstood you ?

True. As long as the sound does not glitch, I don't care if it has like a 10ms latency or a 40ms latency. On my laptop I have absolutely no performance issues with LMMS under ALSA. The project I mentioned in the original post is pretty large and it did not give me a single drop out with all the instruments loaded. Latest version of LMMS 0.4.6 is very stable and performs well. Do I understand you correctly - do you have performance issues with LMMS?

Reply to studio32:

Qtractor is made with electronic music in mind.
"Qtractor, an Audio/MIDI multi-track "bedroom" sequencer for the techno-boy and girl. "

The description can say anything. I am saying that in practice it isn't there yet - at all. It is very difficult to do techno with QTractor. I will explain why further in answering another your question.

I would make the song in the midi sequencer, record it in Ardour and do the final mix e.g. automation and putting effects on it there.

Yeah, well in the type of music I do this is impossible. As I have mentioned earlier, with a complex arrangement I always have to go back and change things, remove sections of the song. If I record everything to Ardour and start automating and then I think that I need to remove the section of the song somewhere in the beginning and also change some notes - I have to remake the whole song. This is not simply an inconvenience - this is a disaster.

Qtractor and Bristol have both Ladish level 1 support:
http://wiki.linuxaudio.org/apps/all/ladish

As far as I can see, neither Level 0 nor Level 1 are actually too useful. I mean - nice standard - starting from the command line. I can see myself doing that during a concert. Ladish is cool, but it is really too basic at this moment and the amount of debates going on in the audio dev mailing lists indicates nobody knows whether it will ever be finished.
Also, ladish required dbus jack which I heard works less good than normal jack.

You say that the modular approach is always lacking. I say, an IME application is always lacking something, and then you're in trouble.
With the modular approach, using JACK (and Ladish) you can make your own DAW with all the features you need.

Yeah, I heard that argument many-many times. And I wholeheartedly agree and understand the history of modular approach and one job tools.
However, "building your own DAW" is a mythical process for most musicians. I am not a programmer and I do not see how I can build my own DAW out of modular approach - only if most of it's work I will do manually by myself. This is not DAW.
As for an often mentioned argument of the limitations of IME apps, in theory all IMEs are limited, but in practice I have yet to see a real life example of limitations of, say, FL Studio. Really, you would have to come up with a very weird and non-standard idea to not be able to easily implement it with that sequencer.
If you do have examples, I would like to hear them.

You should make more clear why making an orchestral piece, with all kind of different instruments and dynamics is so much different then making hardcore.

I already did - multiple times. In hardcore you always need to go back to any point of arrangement and change things. Orchestral piece at least can be pre-composed and what really matters there are notes. In hardcore or house what matters is the sound itself and also precise master sync. I would love to see someone do a solid house tune with modular tools. I am saying that even if it's possible - it is extremely difficult.

It is also not true that on Linux audio, guys 'only' make rock or jazz music. Imo there is a lot of electronic music be made on Linux. Some use LMMS as there core app, some SuperCollider and the like, others take the modular road.

This was a valid generalization. I am well aware of who is using LMMS as a core app, but unfortunately what I hear on LMMS Sharing Platform are mostly sketches or simplistic tunes. It is possible that my tunes are one of the first serious complete works made with LMMS.
Also, note that I am speaking not of electronic music in general, but the type of electronic music that I called complex - which requires master sync and saving a project and to be able to edit everything in that project at any time.

When you say, "hey there is not Ableton Live app on Linux, which can do time-stretching and looping the same way as Ableton Live can do", you're right. But then you might ask your self whether it is reasonable to expect an Ableton Live on Linux made by the community (in a short time).

I am not expecting anything of that sort to be made by the community in a short time.

It might also be true that there is no such tool as FL Studio on Linux, which helps you compose an song very quickly.

It is not a matter of speed. If the difference in speed and difficulty of producing something is enormous - it is a matter of making possible to compose certain type of music or not.

In general, I can see what you are saying, but this isn't what I was talking about. I know all the apps you mention, but apart from LMMS none can help me in my non-ambient work.

Louigi Verona wrote:

Qtractor and Bristol have both Ladish level 1 support:
http://wiki.linuxaudio.org/apps/all/ladish

As far as I can see, neither Level 0 nor Level 1 are actually too useful. I mean - nice standard - starting from the command line. I can see myself doing that during a concert. Ladish is cool, but it is really too basic at this moment and the amount of debates going on in the audio dev mailing lists indicates nobody knows whether it will ever be finished.
Also, ladish required dbus jack which I heard works less good than normal jack.

Jack2 with dbus is NOT less good then normal Jack. BTW you can compile and install -classic and -dbus both at the same time if you want.

You should try Ladish yourself, to get your own opinion. It is at preview 0.2 now, of course 1.0 would have more functions.

There is nothing bad in running something on the command line while at a live session. BTW everything you run can be prepared in scripts, qjackctl patchbay's and/ or as studio/ room in Ladish.

In general, I can see what you are saying, but this isn't what I was talking about. I know all the apps you mention, but apart from LMMS none can help me in my non-ambient work.

First your post did contained pretty some myths. You don't comment on that. For example, your are saying that the linux audio is almost only working and promoting the modular approach. This is not true these days!
It might not be at an state you want/ need ATM but alas.

The lack of support towards LMMS from is community might have something to do with their lack of good Jack support. People who are making music on the Linux platform doesn't see much in a app which can't use the professional sound server daemon (JACK) and restricts the user to an purely IME approach. Probably they rather use and work on tools like Qtractor then. It is an IME, but it uses the professional sound server daemon JACK and you can use dssi plugins like Whysynth, and ALSO connect it to modular apps like Zynaddsubfx and PHASEX (you can't force those devs of those synths to get rid of the modular approach you know, it's just not realistic).

About LMMS and Jack, why do you think Renoise, as an IME, has Jack support?

Your whole post is about the lacking of the modular approach for your workflow. But maybe it's just an lacking of an good FL Studio / Ableton Live solution on Linux. LMMS doesn't satisfy your needs atm.
That's the whole point you're making I think.

And I think having proper JACK support for LMMS, could:
1) improve their position in the community
2) Make the app more usable for more people
3) Makes the app more professional
4) Gives the app far more possibilities, (if you want that or not)

With Renoise you can do a lot, but it's not GPL, and that's not what you want I think.

About the modular approach: I don't say everyone can reach the same results with the modular approach, in the same amount of time, like you can with for example Fl Studio. But when you experiment with applications, learn how they work and dive into session handling, talk with developers, meet other musicians with your style on Linux... there are opportunities for sure.

studio32 wrote: And I think having proper JACK support for LMMS, could:
1) improve their position in the community
2) Make the app more usable for more people
3) Makes the app more professional
4) Gives the app far more possibilities, (if you want that or not)

Don't forget this one:
5. Use firewire interfaces

Currently I can hear all of my apps through my nice studio monitors that are connected to my Firewire Solo. Since LMMS is so unstable under JACK I can only hear it through headphones connected to my crappy onboard audio. Then I render the work to wav and import it to Ardour and work with it there.

Hi Louigi,

You wrote:

As long as the sound does not glitch, I don't care if it has like a 10ms latency or a 40ms latency. On my laptop I have absolutely no performance issues with LMMS under ALSA. The project I mentioned in the original post is pretty large and it did not give me a single drop out with all the instruments loaded. Latest version of LMMS 0.4.6 is very stable and performs well. Do I understand you correctly - do you have performance issues with LMMS?

Oh yes indeed, and with every driver it supports. Now, to be sure, I was trying to lower the latency, but I'll see what happens with very large buffer values. Btw, I use an M-Audio Delta 66 audio interface, is that going to be a problem for LMMS ?

Okay, after reading your posts and the responses it seems that there really are two issues here regarding LMMS and the more general topic of IMEs. The first issue, the one that appears to matter most to you, is one of workflow. And IMO you're correct to insist that your work style does not fit a modular environment. Only you will know that, and I'm certainly not going to tell you how you should approach your work. You want or need the features specific to LMMS, and I support your efforts at making it a better program.

The second issue is that of performance. It matters to some of us more than to others, again according to our chosen workflow. But for those of who would like to use LMMS without the problems of inconsistent audio the outlook isn't good. However, I must also admit that I haven't spent much time adjusting buffer sizes while running the OSS or SDL drivers, so I'll check out LMMS with considerably larger buffers.

Btw, my ancient MIDI sequencer, Voyetra's Sequencer Plus Gold, includes a patch librarian. I realize it's a MIDI-only environment, but in your opinion would that environment be an IME ? It requires nothing outside itself except MIDI hardware or software sound sources.

Thanks again for your input. It's a good discussion.

Best,

dp

studio32:

I will try ladish! I am eager to try it out.

There is nothing bad in running something on the command line while at a live session.

While I am performing and in one hand holding a flute, being there with the audience, I am not very keen at going back to my laptop and starting to type something into a terminal - not how I'd like to see my gigs. Pressing a button - Load Project - is a different story!

For example, your are saying that the linux audio is almost only working and promoting the modular approach. This is not true these days!

The lack of support towards LMMS from is community might have something to do with their lack of good Jack support. People who are making music on the Linux platform doesn't see much in a app which can't use the professional sound server daemon (JACK) and restricts the user to an purely IME approach.

These two quotes from your post - they do not make sense to me. If people are not supporting LMMS because they want JACK support and because it limits them to purely IME - it means that they actually want to use LMMS in a modular environment. Then it is not an IME anymore, at least for those people. I do not understand the use of LMMS in such a way - or, to be more accurate, I do not understand why that should be the priority. I perfectly understand, that being an IME tool, the devs are first of all dealing with functions, more important for IME, than making it a tool which is also possible to be used as a module.

StudioDave:

However, I must also admit that I haven't spent much time adjusting buffer sizes while running the OSS or SDL drivers, so I'll check out LMMS with considerably larger buffers.

Do try. Afaik, the devs are not suggesting OSS (?). Can you try ALSA too?

Btw, my ancient MIDI sequencer, Voyetra's Sequencer Plus Gold, includes a patch librarian. I realize it's a MIDI-only environment, but in your opinion would that environment be an IME ? It requires nothing outside itself except MIDI hardware or software sound sources.

Hm. Could be. But what is software sound sources? If it means synthesizers outside the programm - my opinion would it is not an IME, if by that you mean wav samples - than it is definitely an IME.

Louigi Verona wrote:studio32:

For example, your are saying that the linux audio is almost only working and promoting the modular approach. This is not true these days!

I fail to understand why this quote doesn't make sense to you... It's pretty clear imho.

The lack of support towards LMMS from is community might have something to do with their lack of good Jack support. People who are making music on the Linux platform doesn't see much in a app which can't use the professional sound server daemon (JACK) and restricts the user to an purely IME approach.

If people are not supporting LMMS because they want JACK support and because it limits them to purely IME - it means that they actually want to use LMMS in a modular environment. Then it is not an IME anymore, at least for those people. I do not understand the use of LMMS in such a way - or, to be more accurate, I do not understand why that should be the priority. I perfectly understand, that being an IME tool, the devs are first of all dealing with functions, more important for IME, than making it a tool which is also possible to be used as a module.

Imo if you make an application to make music with on Linux, you should have Jack support. It should be in the basics of the app. Jack is what Linux audio users use for making music. It's made for it. You're missing the point imo if you develop an music app without Jack support. It's not one of the features you choose from, its one of the things you do first when you start developing such an app! Not (only) for its modular possibilities, but also because its made for it, it's quality stuff. So also an IME should have Jack support imho. You say, why should it be a priority. I say, why didn't you start with it!??

Besides that, why would you want to restrict yourself to purely IME? Renoise, Ardour, Qtractor, all those apps are IMEs, but have also Jack support.

You're the one who makes the kind of music you're making. So you probably knows best. But maybe you've worked a lot on the Windows way too, so maybe you have to learn to see more benefits of Jack then...

Anyway, good luck with helping improving LMMS. You're doing a good job. And let's hope it will have proper Jack support soon

Besides that, why would you want to restrict yourself to purely IME? Renoise, Ardour, Qtractor, all those apps are IMEs, but have also Jack support.

No offence meant, but with all due respect, you are greatly missing my point. I am not saying anything about restricting myself to IME - in fact, I specifically mentioned on these forums that I am using a modular setup for live performances - I only pointed out that IME is necessary for the creation of certain types of music. Do not look deeper than that - this is exactly what I am saying and I am not saying that users should be restricted to IME.

IME is a closed unit. It is it's logic. I understand that JACK is a good low latency thing to be based on and I agree that with all things equal it would've been good to just start with JACK and forget about it, once it works ok. But since this is not the case, now spending days and days of development just to implement something that is not crucial to the working of a closed unit such as LMMS is not a high priority. There is really nothing to argue about here. IME is a separate tool. Being able to mix it in into modular environment is a nice additional feature but it is by no means a priority.

As for you examples of IMEs, most of them are incorrect. Renoise is an IME, but Ardour and Qtractor are not.
Also note that Renoise is a proprietary application and thus is not suitable for use for a person who wishes to use libre software. So in the libre software world the only IME application I know of is LMMS.

Do I understand you well that you think that an application which has Jack support is not an IME?

Why is Renoise an IME and Qtractor not?
Is Cubase an IME?

Louigi Verona wrote:... I only pointed out that IME is necessary for the creation of certain types of music...

Linux users often react rather strenuously when they read categorical statements like that.

I don't agree that you need specific software for a certain kind of music-making, but I will agree that some software makes the job easier. However, I can hear how someone might make the same kind of music as your examples within a modular environment. I honestly don't know if it would be easier or more difficult, but I do know that minds & attitudes are often more restrictive than computing environments. In LMMS you've found a solution to your compositional requirements. Another composer writing in a similar style might use a very different environment.

Software is very interesting in that perspective. Creative users routinely make it work in ways it was never designed for, yet they get their work done and are sometimes even happy with it.

Best,

dp

Man, you do not understand me at all, but this may be my fault - perhaps I did not give a clear definition of an IME. So let's give one!

An integrated music environment (IME) is a musical application which facilitates a full song creation cycle and does not require any software outside itself to create music.
Typically, some musicians would still use post production mastering tools, however latest IME's do include mastering tools so that today it is fully possible to work entirely inside one program.

So now we can see whether a given app is an IME or not.
Renoise is an IME since it requires no external applications to reach it's goal. Cubase is an IME as well.

Qtractor, I must admit, IS an IME - I sincerely apologize for that. I forgot that Qtractor can use LADSPA and DSSI instruments internally, by adding them to a channel. Such functionality makes Qtractor an IME.
Ardour, however, is not IME. It will become an IME with the addition of midi. I don't know if it will be able to work with LADSPA and DSSI instruments internally, but I suspect it would. If, however, it will not be able to work with them internally and you would have to start them outside Ardour and route Ardour's midi out into their midi in - that would not allow Ardour to qualify as an IME.

I see that I was not clear in agreeing with several of the points you raised.
1. I agree with your statement that linux community is, in fact, supporting IME as a concept.
2. I also agree that a lot of software is moving towards that goal.


StudioDave:

However, I can hear how someone might make the same kind of music as your examples within a modular environment. I honestly don't know if it would be easier or more difficult, but I do know that minds & attitudes are often more restrictive than computing environments.

Please, read my statements carefully While I am just a human being who makes mistakes, I usually try to be very careful with my wording. I never said it was impossible to make something like my examples, in fact, I clearly said that it was. But the amount of work, I claim, is several times larger in order to achieve same result with a modular approach. And by several times I mean, for instance, 5 times larger. This a serious coefficient.

I will be happy to be proven wrong. But since I suspect that not a lot of my readers are into the type of music I do, I doubt someone can offer any such proof. My arguments are pretty solid, I believe, and although it does sound categorical, this is indeed my claim - modular environment makes it impossible to produce certain kinds of music.

Of course, by impossible I do not mean physically impossible. It is possible to paint a castle with a small brush, but it is such an unreasonable method, that it is virtually impossible in real life.

To make my statement scientifically accurate and perhaps less categorical, it can be rephrased to this:
Modular environment makes it extremely difficult to produce certain kinds of music, to the point of choosing not to use GNU/Linux to achieve the task.

Yeah, and wanted to add that the LMMS-JACK issue, I would of course welcome LMMS having JACK support. Since all the downsides of LMMS could've been substituted by external applications until they are fixed.

Also wanted to note that I do consider the latest version of LMMS to be a very confident, serious app ready for in-depth use.