In what way modular approach is limiting

Discuss how to promote using FLOSS to make music.

Moderators: MattKingUSA, khz

Post Reply
User avatar
Louigi Verona
Established Member
Posts: 402
Joined: Mon Aug 24, 2009 8:56 am
Been thanked: 1 time

In what way modular approach is limiting

Post by Louigi Verona »

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.

First of all, I would like to underline the fact that I do believe that modular approach is something that makes GNU/Linux stand out. If one requires a special, complex setup, modular approach is the way to go - installations, live performances, non-standard signal processing. All of that is usually not possible with Integral Music Environments (later as IME, meaning a standalone, all-in-one DAW).

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.

Let's then see what kind of music is easy to do in Linux today.

Well, generally speaking, the best type of music that fits Linux is actually recording bands. Putting it shortly and yet descriptive: recording acoustic music and then post editing those recordings.

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.

Of course, before anyone says that the above tools can do much more than that, I should agree that they can. But the amount of workarounds, setup and/or limitations in order to produce other types of music other than mentioned above is at most times increasingly larger than incentive to produce it using Linux.

And thus we come to limitations of the modular approach.

1. Not suited for certain types of music.

My belief, as an electronic musician, that modular approach is not an optimal approach for complex electronic music. By complex electronic music I mean music with highly detailed arrangements, which requires the musician to go back to any place in the arrangement and change something, anything - be it a note, it's placing, a parameter, its automation, sound source.
Please, do not be fooled by the word "complex". A tune can become technically complex very fast without being a masterpiece of detail. Most house tunes can be relatively complex with various automations, break downs and build ups.

That for this kind of music modular approach is probably the worst approach is clear to anyone who has ever attempted it.
The reason why this is rarely brought up is because by my observations most musicians who hang around Linux Audio communities are rock bands, jazz bands and people who produce songs and music that requires no technically complex arrangements (which by no means indicates that the music itself is uninteresting). Recording your voice and then layering some basic drums with Hydrogen and then adding some orchestral elements like strings, a flute phrase and possibly an organ is not difficult to achieve in Linux. In fact, being able to stick the required synth into Ardour or QTractor and record what you need makes everything charmingly inspiring. This is where modular approach only helps the workflow.

Not so for complex electronic music. It requires much more than being able to input notes. And the possibility of having a session handler is not a solution. While some may say that having dozen of programms open is just a matter of getting used to or even taste, in reality it is plain inconvenient - in fact, something as simple as producing a decent house tune with modular approach is quite difficult, to say the least. Not only you need to sync everything, the amount of work required to build up the arrangement, to introduce sudden break downs and parameter automations makes it quite, I would say, uninspiring.
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.

In other words, using modular approach for doing complex electronic music is same as using a toothbrush to wash the floor - it can be done, but the only good reason to use that method is if you really have too much time on your hands.

All of the above can actually be demonstrated - and with free software.

Let's look at a tune I made using LMMS. Here you can get both the ogg rendition and the source project with all the samples: http://lsp.lmms.info/index.php?action=show&file=828

This is not the most detailed arrangement I've done and is certainly not the most detailed arrangement typical for that kind of electronic music. However, I am claiming it is complex enough to be very difficult to set up and create using modular approach (although possible).
In case you do not have the time to open (install) LMMS 0.4.6 and download all the required samples, let me break it down for you.

The tune uses 27 instruments, out of which there are:
3 Mallets synths
3 sf2 players
3 Zyn synths
17 audio plugins (wave samples, 7 of those are used as melodic instruments in a piano roll, 10 just sounds like drums and effects which require no piano roll but a drum machine kinda editor)

The tune has 40 separate midi tracks.

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.
Okay, let's picture that eventually I am using Ardour. Where would I have midi? Ardour does not support midi, so I would have to use, say, QTractor, to write midi. I did not try syncing these two DAWs via JACK transport, but if, say, it is possible, I would have to manage all the clips in two separate programms and align them almost by ear, constantly switching between two different windows, because some things I just need to have in precise positions. If, at some point I would need to remove or add some midi/audio clips into the middle of the composition, I will have to move all the clips in both programms.
Next, I am using some volume and panning automation. QTractor has no automation, so eventually, once the basic structure is done, I would have to export midi clips from Qtractor to audio clips and put them into Ardour and there automate the volume and panning. If suddenly I realize I have to change smth (which happens often during production) I would have to go back to QTractor, change the midi clips, re-render the clips and then re-export them to Ardour. I am not sure if I would be able to copy the automation easily - if no, then I would have to redo it again.
I can, of course, go a simpler way and just route QTractor to buses in Ardour and do the automation instantly from there - this would work if JACK transport works well for Ardour and QTractor.
I also use various controllers to automate synth parameters, effects and the amount of wet gain on a track. How it is possible to do in modular approach I do not even know. Effect automation is, of course, possible through mixer in Ardour. How to automate other things I am not sure. Maybe it is my lack of knowledge in this area, maybe it is not possible.

All in all, the above description shows that it is possible to make such a tune without IME, but it is much more difficult, since you will have to switch between two separate DAWs and also constantly care about what is routed to where. Keep in mind, LMMS 0.4.6, being stable and sweet to work with in as it is, is far from offering all the flexible functionality that most modern proprietary DAWs do. Once it has routing capabilities and a whole other list of improvements, which are a logical continuation if what is there now, imitating its workflow with a modular environment will shift from "difficult" to "impossible".

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.

The whole convenience issue is, actually, extremely important. I have often observed that complaints of IME type of musicians about modular approach being too difficult to set up are either ignored or treated as a sign of weakness and/or lack of desire to do music the "linux way". But I personally see no point in such persistence. After all, IME approach is an approach which can greatly improve what can be done on GNU/Linux and - as many might admit - help to make music making on Linux a solid good experience, instead of shifting it closer to things like programming or chemistry, with all the low level code and several line formulas. After all, convenient does not mean bad.

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. 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.

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.

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.

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.

4. In theory, modular does offer more functionality than IME, but the majority of musicians really would prefer a stable system to produce more regular types of music than difficult rocket-science-type setups to get some additional effects not achievable in standalone, IME type DAWs.
Atm, due to historical reasons, I presume, and to the fact that modular approach is still being considered the only thing worth doing on Linux, making normal, usual electronic music is difficult.

I hope this article will be useful and would bring on some meaningful discussion.
User avatar
spm_gl
Established Member
Posts: 358
Joined: Wed Apr 22, 2009 7:58 am
Location: Spreewald, Germany
Contact:

Re: In what way modular approach is limiting

Post by spm_gl »

Interesting post. I'm not a musician, so I can't really comment much. But trying to make electronic music in Ardour is similar to trying to make electronic music in ProTools(TM). It's a DAW. I'd go crazy if I tried to record a band or edit a song in Abelton Live.
--- Spreemusik ---
Jan Fuchsmann, Audio Engineer
Check our blog at http://www.spreemusik.com/blog
SR
Established Member
Posts: 218
Joined: Wed May 07, 2008 6:01 pm
Location: Houston, Tx

Re: In what way modular approach is limiting

Post by SR »

All good points. LMMS is a neat app but, as a guitarist, it doesn't satisfy any of my needs. IMHO, we need more widespread adoption of session management and after that the IME's will come.
User avatar
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

Post by Louigi Verona »

But trying to make electronic music in Ardour is similar to trying to make electronic music in ProTools(TM).
Unfortunately, not. Pro Tools has midi. Ardour does not.

When Ardour will have midi, it will in many ways become very close to becoming an IME. However, the fact that synths are not "inside" Ardour makes it impossible to do many things - like automate synth parameters and save a project as a whole, with all the midi sound sources. But again - once Ardour implements midi well - it will become a very powerful app, which will be somewhere in between modular and IME. When that happens, we will see what the new possibilities and work flow would be.
laba170
Established Member
Posts: 53
Joined: Fri Jul 31, 2009 5:22 pm

Re: In what way modular approach is limiting

Post by laba170 »

If I understand you correctly, it's the lack of automation that's the biggest problem. Can't say I disagree, but lack of automation is the only thing that's really bugging me. The rest (synths, sequencers) are okay. (For my use at least)

Would've been nice if we could route automation levels just as easily as we route audio and MIDI, and we had sequencers/synths that could connect all automation automatically. "Jack-automation" or something. Would such a thing be possible?

I've also tried LMMS a little, but it's a little unstable. Also, I don't like the sound produced by it. For example, It seems as if Zynaddsubfx sounds better as an external app than as a plugin in LMMS. But maybe I'm only imagining this...
Last edited by laba170 on Wed Feb 24, 2010 9:36 pm, edited 1 time in total.
User avatar
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

Post by raboof »

laba170 wrote:If I understand you correctly, it's the lack of automation that's the biggest problem.
That, and session handling ('song X needs synth Y with preset Z', right now you'll have to start 'song X' in one application, start synth Y, choose preset Z, and connect the application to Y. I can see how that would be cumbersome.
Would've been nice if we could route automation levels just as easily as we route audio and MIDI
I'm not too familiar with all this, but shouldn't it be possible to encode most automation features in MIDI messages?
laba170
Established Member
Posts: 53
Joined: Fri Jul 31, 2009 5:22 pm

Re: In what way modular approach is limiting

Post by laba170 »

raboof wrote:That, and session handling ('song X needs synth Y with preset Z', right now you'll have to start 'song X' in one application, start synth Y, choose preset Z, and connect the application to Y. I can see how that would be cumbersome.
I get your point. For my modest use though, It's not a big deal. I guess I would experiment with ladish/LASH if I did more complex stuff. Is it any good, by the way?
User avatar
spm_gl
Established Member
Posts: 358
Joined: Wed Apr 22, 2009 7:58 am
Location: Spreewald, Germany
Contact:

Re: In what way modular approach is limiting

Post by spm_gl »

raboof wrote: I'm not too familiar with all this, but shouldn't it be possible to encode most automation features in MIDI messages?
That's how they did it last millenium. Cubase on an Atari sending out Midi CC's to hardware synths, and then recording that with ProTools (which didn't have Midi before version 6.x)
No, it's not very comfortable or versatile.
--- Spreemusik ---
Jan Fuchsmann, Audio Engineer
Check our blog at http://www.spreemusik.com/blog
User avatar
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

Post by Louigi Verona »

laba170 wrote:I've also tried LMMS a little, but it's a little unstable. Also, I don't like the sound produced by it. For example, It seems as if Zynaddsubfx sounds better as an external app than as a plugin in LMMS. But maybe I'm only imagining this...
LMMS 0.4.6 is a stable release - in fact, it hasn't crashed on me once.
As for sounds which LMMS can produce, I think lots of people are making their conclusions out of the lousy ogg samples which are included with the installation. The sounds which LMMS can produce are the sounds which you make it produce.
As for what you say about Zyn, I am not sure I hear the difference. Could it just be your impression?

Please, listen to this tune. Certainly not a masterpiece, but definitely shows that LMMS can output pretty solid sound: http://www.louigiverona.ru/files/sample ... cooter.ogg
User avatar
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

Post by Louigi Verona »

laba170 wrote:If I understand you correctly, it's the lack of automation that's the biggest problem. Can't say I disagree, but lack of automation is the only thing that's really bugging me. The rest (synths, sequencers) are okay. (For my use at least)
The automation, the session, the master sync.
StudioDave
Established Member
Posts: 753
Joined: Sat Nov 01, 2008 1:12 pm

Re: In what way modular approach is limiting

Post by StudioDave »

Louigi Verona wrote:... I do not agree with people, who say that GNU/Linux should stick with modular approach and stream all energy in that direction.
Alas, there is NO-ONE in charge of these things. Everything that exists in Linux exists because someone "scratched an itch", i.e. they did it because they wanted a particular kind of program or feature. And they either learned to code it themselves or they lobbied or even paid coders to get it done.
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.
I suggest that there is no such community. A "core" community would share a common idea about what constitutes the aims and objectives of the community at large. Certainly the Linux Audio Users list indicates that there is no such agreement. If there is a common or shared focus it's probably on JACK and its utility.

[Note to self: Can there even *be* a community of anarchists ?!]

In 2000 there was only the LAU list. Now we have Linux audio-related forums at KVR, at Cockos, at the Ardour site, at Gearslutz, at SoS, and so forth.

Consider the following questions:

How many users here are subscribed to other forums, mail-lists, etc. that are about Linux audio ? How many of those forums do you think there are already ? How many Linux audio developers are subscribed to this forum ? Are they the developers you need to be speaking to ? If not, are you making the efforts to reach the developers who share your vision ?

I'm not trying to be offensive, btw. I've read your post a few times now, and you make some excellent points. However, it still seems to me that there are only a very few ways things get done in Linux software development: Either learn to make or fix it yourself, or find someone who knows how and figure out a way to get them to do it for you. With sufficient input from users devs will introduce requested features, but without that input they'll happily please themselves.

Btw, that's how things stood when I got into Linux. It was not uncommon for new users to find that they had to learn some C or Tcl/Tk in order to fix problems. I repaired the Linux MIDI support in Csound in the late 90s and I have zero training as a programmer. Later I ported SGI audio software to Linux, again simply learning by doing. My point is that I did that work because I wanted other things to happen.

Everyone likes to eat. We like to open a box and consume its contents. We don't want to think about how it was produced, we don't care how it was packaged, we don't want to know how to grow our own food, we're just hungry and want to eat now. That is the typical consumer.

Then there's the untypical consumer, the one who does indeed want to know what's in his food, who considers it a matter of importance, and who is willing to change his habits if he feels a better end will result. This one makes an effort, the other one just eats.

And that's all good, I have no complaint about that state of affairs. Not everyone can have a garden or farm, and not every gardener or farmer is good at what they're doing. Differences make the world interesting. However, in its early days Linux was definitely a system reserved for the one who made an effort to contribute to system development. Now, thanks to Ubuntu and other more user-friendly distros we see more people coming into Linux, and they're coming into it with preconceptions and expectations that may be unrealistic at best and wrong-headed at worst.

UNIX/Linux is a modular environment and has always promoted modularity as a system. However, you are correct to note that the modular approach should not be accepted uncritically, especially with regards to music and sound software. Further, there's no particular reason to assume that Linux somehow can't handle a non-modular approach to software design. This is to say that yes, what you want is do-able in Linux, but the system was not designed originally for it and you may have trouble convincing some software developers that the more integrated approach is valuable as well.
Well, generally speaking, the best type of music that fits Linux is actually recording bands. Putting it shortly and yet descriptive: recording acoustic music and then post editing those recordings... the way the workflow is shaped, is aimed at producing melodic music, similar to orchestral aimed Cakewalk in the early nineties.
This is a fairly accurate summary *as regards the programs mentioned*, but read on.
Of course, before anyone says that the above tools can do much more than that, I should agree that they can. But the amount of workarounds, setup and/or limitations in order to produce other types of music other than mentioned above is at most times increasingly larger than incentive to produce it using Linux.
What "other kinds of music" are you thinking of ? Like this:

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

Or this:

http://linux-sound.org/audio/trio4fgb.ogg

Or this:

http://linux-sound.org/audio/studiodave ... l_ride.mp3

The first piece was created with Csound via AVSynthesis. It is probably impossible to do something similar with any IME I know of. It is also, btw, what I think of when I use the term "electronic music". The other two pieces are MIDI sequences in more familiar styles.
And thus we come to limitations of the modular approach.
From here on I can only suggest that you continue to put your energy into pushing the LMMS devs to adhere to your vision. You're not likely to convince the Ardour devs to change that program's design, although Ardour3 is getting closer to your model.

Btw, you're right of course when you state that not all Linux sound and music apps use JACK. However, that is not a recommendation. Ignoring JACK is unwise and extremely short-sighted.
I hope this article will be useful and would bring on some meaningful discussion.
Thank you for your thought-provoking message. You've obviously given the matter considerable attention. I don't see the situation quite the same as you - I have a little longer relationship with Linux - but I think you've made some solid points that should be discussed with some specific people.

Louigi, you need to be addressing the LMMS devs more directly. You should send them a copy of your post. I think you need to push them for better JACK integration too, then you can have the best of both worlds. Your IME can remain sealed, but JACK connectivity would allow the use of external programs if desired.

Btw, you should also convince the LMMS devs that they need to include your music as representative of what can be done with LMMS. Too many current examples simply reinforce the (admittedly wrong) impression that LMMS is just good for making disco and techno dance-beat music. I would have been far more interested in getting deeper into the program if I'd heard your examples first.

Best regards,

dp
User avatar
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

Post by Louigi Verona »

Hey man!
Thanks for the detailed answer.

To comment shortly, I am speaking to the LMMS devs and at least one of them has read this post. I think I am also one of the most active feedback givers in the latest months. I think LMMS is going the right way and basically they all agree with this vision, as far as I can see.
I am not sure what making it JACK compatible has to do with making it a good IME though. In fact, I believe that this kind of modular thinking is what makes people beg LMMS devs to make it JACKified. But this is absolutely not the highest priority of the project. If there is no JACK support, LMMS can function very well since it has everything inside itself. As an active LMMS user I can confidently say that providing JACK support would not change much in what LMMS can do - it will just provide a modular audio environment with yet another module. I believe this is not the goal of LMMS.

Also (and this is important!) I am not asking or even wanting Ardour to become IME in question. I was just addressing numerous comments which people were saying, even on this forum. I think, unlike proprietary systems, GNU needs just one very well working IME. I see no reason in having many. Ardour is good for what it is and it is required the way it is by many people, as far as I can see.

The point that there is no consensus on anything is taken.

Putting demos of my songs on LMMS page, imho, is important in bringing more interest to the sequencer. Many good apps might not be recognized if not some cool songs. I have contacted Paul about it, but so far he has not replied. Each time he said he has to listen to the songs and although I have pointed him several times towards them, there has been no action. I suspect he just did not have the time yet. I do not want this to seem like a desire for fame and such. In fact, I would not mind if the tunes would be demoed anonymously.

The music you linked... the first tune sure does not need IME. As I wrote, by complex electronic music I mean music which needs master sync (all elements synced to one clock), detail and the necessity to have a "project" and return to any point of the tune to change smth.
SR
Established Member
Posts: 218
Joined: Wed May 07, 2008 6:01 pm
Location: Houston, Tx

Re: In what way modular approach is limiting

Post by SR »

Louigi Verona wrote:If there is no JACK support, LMMS can function very well since it has everything inside itself. As an active LMMS user I can confidently say that providing JACK support would not change much in what LMMS can do - it will just provide a modular audio environment with yet another module. I believe this is not the goal of LMMS.
This is really only true if you never plan on recording live audio or using a firewire interface. I would like to be able to use LMMS but I can't because it doesn't do everything I need nor does it interface with the apps that come close. The devs have already said that my needs aren't a priority and that they would rather focus on cool and exciting new features. Unfortunately those features won't make it any more usable for me so I just have to keep holding out hope that the JACK support will stabilize.
User avatar
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

Post by Louigi Verona »

I think the reason they say that it is not a priority is because LMMS and IME of such type (like FL Studio, Cubase) are usually less suitable for recording things. If you want to record things, you go Pro Tools (Ardour).

This is exactly what I am saying. Musicians that need IME to programm electronic music that needs sync rather than record it are a rarity in the Linux music scene. And this is what kept me from switching to GNU/Linux for a long-long time, until I saw that LMMS is mature enough and also as I shifted more towards ambient. If I would've been a house music guy - there would be no way I would switch to Linux and not have my proprietary software running perfectly in WINE.
StudioDave
Established Member
Posts: 753
Joined: Sat Nov 01, 2008 1:12 pm

Re: In what way modular approach is limiting

Post by StudioDave »

Louigi Verona wrote:I am not sure what making [LMMS] JACK compatible has to do with making it a good IME though. In fact, I believe that this kind of modular thinking is what makes people beg LMMS devs to make it JACKified. But this is absolutely not the highest priority of the project. If there is no JACK support, LMMS can function very well since it has everything inside itself. As an active LMMS user I can confidently say that providing JACK support would not change much in what LMMS can do - it will just provide a modular audio environment with yet another module. I believe this is not the goal of LMMS.
All very good, but not so correct re: JACK's significance. Connectivity is not JACK's only virtue. Sample-accurate sync, dropout-free performance, low-latency - how does LMMS *not* benefit from such technology ?

Also, the devs might consider what others are saying here too, i.e. that they *would* use LMMS if it had decent JACK support. I'm sorry, I just don't get why JACK support is a low priority, unless the program's internals are written in such a way as to disallow decent performance with JACK. After all, improving the JACK support doesn't take anything away from the program, right ?

Frankly, I'd love to use the program, but my composing environment is indeed modular and entirely based on JACK support. IMO no single program will ever have "everything" I need when composing, simply because I don't always know what I'll need before I begin the composition. Worse, without decent JACK performance LMMS must be run alone and worked in without the ability to sync and reference its output to other parts of my piece. I know that I'm talking composition style now, but I think it's relevant.
Putting demos of my songs on LMMS page, imho, is important in bringing more interest to the sequencer. Many good apps might not be recognized if not some cool songs. I have contacted Paul about it, but so far he has not replied. Each time he said he has to listen to the songs and although I have pointed him several times towards them, there has been no action. I suspect he just did not have the time yet. I do not want this to seem like a desire for fame and such. In fact, I would not mind if the tunes would be demoed anonymously.
Screw that, get your name in the lights, man ! Let them know who did it and how. :)

Seriously, if Paul G's reading this he should take a tip and listen to your pieces asap.

Finally, I want to emphasize that I'm not inimical to LMMS. It is a good program that suits the needs of many composers and I want to see its development continue.

Thanks again for your thoughtful response, Louigi. I look forward to hearing more of your music and I hope your influence is felt at LMMS Development Central.

Best regards,

Dave Phillips
Post Reply