In what way modular approach is limiting

[studio32]

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.

Ok, things become more clear to me now.
It also looks like the defenition of IME is a bit subjective. I think Ardour is also an IME, but only for audio atm. Why does midi belong to the definition of an IME and OSC not, for instance? If an app is an IME seems to depend on what the user needs for his music. Some might need midi, some not. Some might need VST, some not.

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.

That is exactly what I tried to say. Why wait till the zynaddsubx-internal-synth is ready, when you can use zynaddsubfx with LMMS via Jack? Why wait till the sf2-synth is ready, when you can use LMMS with qsynth? etc. etc. etc.

But again, besides that, Jack gives you better sound performance.

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.

Cool!

[StudioDave]

I think we're at something of an impasse of confusion here.

Louigi, at this point what is that you want to achieve in this thread ? If you want to convince someone that LMMS is worthy of their attention you can only do so if it suits their compositional needs. If you want more development attention paid to IMEs for Linux you need to address developers.

However, I'm not sure what else needs to be said on the topic. You like LMMS the way it is now. Alas, it just doesn't perform well enough for me, and I'm *not* talking about its utility in the compositional process or its applicability to any particular musical style. Its performance is not good on my system, and in order to get it working at all well I have to forego all of the virtues of low-latency. Cranking buffers up to 2048 and beyond guarantees terribly high latencies.

I think you're wrong to assume that most or any of us don't know what an IME is or is good for. Many of us have come here from Windows or the Mac, environments in which monolithic apps are the norm. Getting anything to talk to anything else is near impossible in those environments. I was happy to leave Windows in part because of its inability to promote modular networks of music and sound software.

Btw, Csound is certainly capable of doing everything within itself. I guess you could call it an IME. Could you compose something like this piece in LMMS :

http://linux-sound.org/audio/studiodave ... 091229.ogg

I think you could do it, but Csound qua IME is a very different beast from LMMS. And no, I don't think it would be an easy task to compose your LMMS music in Csound, despite it being an IME. The piece linked above was composed entirely with Csound, btw, and with NO external processing by other software or hardware.

Okay, I just built LMMS 0.4.6 on a 32-bit Jaunty system with 4G RAM and a 2.4 GHz CPU. Let's do some tests and see what results we get:

1. Started LMMS and opened BlueWolf's Dream Travel. Latency is set for 5.8 msecs. Any movements of a window or panel causes audio glitching, as does switching workspaces.

2. Restarted LMMS with 46.8 msecs latency. Identical results. Driver is ALSA for both cases.

3. Loading the Luxonix LFX VST plugin nearly freezes the system and five minutes later I'm still waiting for it to load. Meanwhile the system is unusable. After three more minutes I was finally able to switch to a VT and killed the LMMS process. Incidentally, the Luxonix plugin is one of the most stable plugins I run in Ardour and elsewheres.

4. Restarted LMMS, still with large buffer value for ALSA. LADSPA fx load without troubles. DSSI-VST plugins load okay, but without native GUI. Tried loading another stable VST, same results as last time.

5. Restarted LMMS with JACK. Used normal latency settings, xruns started right away. Reset latency in LMMS to 8192 frames, latency 186 msec (4096/93 in JACK). Glitching was gone, I could move between workspaces and windows without glitches.

According to these unscientific results it seems that LMMS is usable in realtime with JACK as long as the buffers are set very high. It also seems that VST support is problematic, not surprising for any Linux sound program that supports loading and running native Windows VST plugins.

Best,

dp

[Louigi Verona]

It also looks like the defenition of IME is a bit subjective. I think Ardour is also an IME, but only for audio atm. Why does midi belong to the definition of an IME and OSC not, for instance?

This is a good point.
However by midi (sorry, bad choice of words this time) I meant being able to use a piano roll to trigger synthesizers, not specifically a protocol. Being able to play synths inside of app.
My IME definition is general. Of course, you are absolutely correct, if you do only recording in Ardour and nothing else - it is an IME in your case. But generally people do more that record. An IME is a standalone app, suitable for most types of music, I would add. That is - it is done as a generalized music studio capable of multi-functionality.

Louigi, at this point what is that you want to achieve in this thread ? If you want to convince someone that LMMS is worthy of their attention you can only do so if it suits their compositional needs. If you want more development attention paid to IMEs for Linux you need to address developers.

I just wrote an article pointing out my insight into limitations of the modular approach the way I see it now. I do not wish to convince anyone of anything, just voiced my thoughts and had a good discussion with you guys on the aspects of linux audio. I set no ultimate goal for this thread.

[StudioDave]

I just wrote an article pointing out my insight into limitations of the modular approach the way I see it now. I do not wish to convince anyone of anything, just voiced my thoughts and had a good discussion with you guys on the aspects of linux audio. I set no ultimate goal for this thread.

Cool. It's been a good discussion, thanks for starting it.

Best,

dp

[laba170]

Thing is, nothing can beat a list of channels with appropriate samples and synths on every channel and a master sync above it all for this kind of music. And while JACK does have the JACK transport, my experience shows that it does not really work as a master sync the way it works in an IME, not to mention that not all Linux audio software supports it..

I don't really understand. What can a master sync inside an IME do that jack transport cannot?

I'm not too familiar with all this, but shouldn't it be possible to encode most automation features in MIDI messages?

I have been checking what is possible with MIDI-automation now. With seq24 and zynaddsubfx, I can control for example control panning and volume. These are quite useful, but of course it's not possible to change the internal stuff like attack time and filter frequency.

I still think JACK eventually should take care of automation, in addition to MIDI and audio. Then automation would be flexible, as you could connect anything anywhere manually. And apps could fix JACK connections automatically for the more regular tasks, just like Ardour already does for audio.

[Louigi Verona]

I don't really understand. What can a master sync inside an IME do that jack transport cannot?

Simple - not all software supports it.

[studio32]

I don't really understand. What can a master sync inside an IME do that jack transport cannot?

Simple - not all software supports it.

A serious Linux audio production app does support Jack and jack transport.
There are limitations of the jack transport for sure, as stated before, like looping.

[Louigi Verona]

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.

[raboof]

I can control for example control panning and volume. These are quite useful, but of course it's not possible to change the internal stuff like attack time and filter frequency.

I still think JACK eventually should take care of automation, in addition to MIDI and audio. Then automation would be flexible, as you could connect anything anywhere manually.

So an 'automation transport protocol' should be open-ended to allow user-defined/not-yet-standardized automations (like attack time and filter frequency). Doesn't MIDI already allow that?

I'm all for more automation possibilities, but it seems the problem is one of application support rather than the age of the protocol. If people aren't implementing it using the already-ubiquitous MIDI, why would they implement it with some new mechanism no other apps support yet?

[studio32]

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 I don't know Kluppe well... I 'll check it out. File a feature request there...


Mmh automation..... Non-automation, like Non-mixer etc.???

[Louigi Verona]

The guy behind kluppe is very busy and he is basically not working on it anymore. I looked at the source code, did some very simple modifications, but apart from changing colors and making it to not autoconnect to capture, I am afraid my programming knowledge does not allow to do anything else.

But this is what I am talking about. The modular approach, in order to work perfectly, needs too many people to work together, too many independent projects to comply with one standard.

[SR]

But this is what I am talking about. The modular approach, in order to work perfectly, needs too many people to work together, too many independent projects to comply with one standard.

It works both ways. With a monolithic approach your needs might not be a priority of the developers. Imagine that you can't even use the application because the developers don't feel like working on a feature that you require. At least with a modular approach you can always plug in an equivalent module.

[studio32]

The guy behind kluppe is very busy and he is basically not working on it anymore. I looked at the source code, did some very simple modifications, but apart from changing colors and making it to not autoconnect to capture, I am afraid my programming knowledge does not allow to do anything else.

But this is what I am talking about. The modular approach, in order to work perfectly, needs too many people to work together, too many independent projects to comply with one standard.

Look at Ardour, from your perspective it is missing midi, native linux vst support, advantaged time stretching, etc.
So imo opinion you can't say its (only) an 'failure' of (specific) the modular approach...
Also one application which is gone dead, is not an example for all the projects...
Like I said before, you don't need many fulltime devs to develop a little app which certain features... that could be an advantage...
But I agree with you that collaboration and 'project management' could be better in the LAU world. One step in the good direction is openoctave project... But also Jack is, along with the controversies, and LADSPA are good examples...
You need good programmers, good quality, but also an active user community to survive as an application imho. If you have a solo project and don't work together with other people, (or by chance), people don't pick up your app, don't see the value of it, you could die. You also better have more devs working on an app, so it don't die if one stops (the benefit of open source of course it that 'everybody' can make it alive again...)
It could even be the case the Kluppe has died because of their lacking Jack Transport support... Or maybe apps like sooperlooper or freewheeling are just more popular...

[Havoc]

Just to trow a different angle into this discussion: does you music requires an IME, or do you require an IME because of some ingrained workflow?

To be honest I don't see any good reason for an IME. You want to be able to have a piano roll that triggers all channels (a master) and the synths must be internal for this synchronising. But in fact everything could be separate inside the same app, inside the same pc, outside the app or even outside the pc. The only thing you really need it to be able to let some master control the rest (whatever that might be) and be sure everything stays synced. That and the possibility to store and recall the setup as a single item. The rest is workflow.

I agree to a certain point that not everything is possible because not all synths bring out all controls in a way that lend themselves to control from "a master".

[autostatic]

Discussing this topic is really cool but in the end it boils down to the fact that you either prefer the monolithic approach or the modular one. If you like the monolithic approach, you can jump high and low but since GNU/Linux is like built on modularity it will never happen. LMMS is a cool application, I like it, but considering GNU/Linux and modularity it doesn't really fit in. The devs should really implement solid JACK support otherwise I foresee LMMS never ever attaining version 1.0.x, it will die off before that. Why? Because LMMS is an open source application and like any other open source app it could benefit from feedback from users. Users who use JACK for audio production for instance. Those users happen to be the majority on GNU/Linux. If you exclude those users your project will get abandoned in the long run. I already see it happening now. The LMMS mailinglists are dead quiet, so is the forum.
Just my 2¢, but hey, I'm really in favour of the modular approach. It is one of the main reasons I chose for doing my audio stuff with GNU/Linux.