A fresh start for LMMS

[pgib]

Hello everyone, this is Paul Giblock (pgib) from the LMMS project. As you know, LMMS is quite old. Also, it has several issues related to performance, reliability, and JACK support. LMMS's core is fairly old, undocumented, and tightly coupled. This makes it exceedingly difficult for me to add more features. Therefore I started a rewrite a month or two ago and now I need your help!

Non-developers: Here is your chance to shine! What do you like most about your current audio software? What do you despise? Which GUI layouts do you like and how would you organize workflows? Software like LMMS has many facets. Therefore, we need to provide the user with a song editor, pattern editor, mixer, automation editor and so much more. The easier the user can move between tasks -the better. Also, new features can make life easier. For example, we are considering MIDI profiles to ease MIDI-connections, the ability to share patterns across songs, etc. I need your help in deciding how to best do this! I believe everyone on this forum an come up with one good and unique idea.

Designers: Particularly if you are a UI designer or artist - we can use your help with user interface decisions and with artwork (color schemes, icons, custom widgets..) The project will ship with at least two themes: Native look&feel, and Cusis (http://www.kvraudio.com/forum/viewtopic ... c&start=45) Also, logos are always nice to have.

Developers: The new architecture is a micro-core with plugins to implement most features. The core is largely derived from the LV2 standard. Because of the modular approach, it should be fairly easy to have multiple developers work on new features at the same time. If you aren't interested in coding, we still have room for suggestions. For example, how would you handle the project-file format? By the way, the current thinking is a project is just a directory with multiple files in it - one for each song, pattern, preset, etc. Projects can be shared as an archive.

Web designers: We need a website! Get busy, it was due yesturday!

Translators: I plan on contacting all the current translators for LMMS to see if they are interested. I know some of them are unreachable. So if you are a master at English and at least one other language - please contact me.

The working title of the project is "Unison". I know that there is a Unix tool called Unison. This is really just the name of the initiative, we can come up with more clever branding later

Please Please Please email me if you have even any remote interest in this project! The goal is for this project to eventually replace LMMS. You can visit our current project page at http://sourceforge.net/projects/unison/ please note that there is not much information on the page. Also, note that the current source code is rather out of date and does not reflect Unison's newer, modular structure. The big issue right now is compiling the requirements for the user experience.

If you do not fit in any of the categories below, then just reply and say "Hi"

Regards,
Paul G

[funkmuscle]

that's some amazing news...
I've used LMMS many times but yeah, without jack was frustrating...
I don't have a clue on how to program but will be more than willing to be a tester.

a drum editor would be real cool. Drawing a blank at the moment but will add ideas as you go along..

[pgib]

Yay. Our first response. I will check back on this thread every couple days to gather ideas and direct the conversation. I'll try to maintain a list of the currently accepted ideas. The great thing is - non-programmers are the most valuable resource to me right now. We need ideas from users who actually USE the software.

a drum editor would be real cool. Drawing a blank at the moment but will add ideas as you go along..

Yeah, I'm thinking about that too. Let me know if you come up with ideas. LMMS has a weakness where you need a separate track for each drum. Perhaps a drumkit instrument is in order (assign a generator to individual note values). Then, I guess the next step would be to have a drum-tab editor instead of being forced into the piano roll? And ideas?

[laba170]

I suggest that you download the FL studio demo (maybe it works in wine if you don't have a windows partition) It is very similar to LMMS, so you will be able to compare the two. Even though they look similar, Fl studio is a lot more polished of course. Anyway, my main issue with LMMS is lack of performance, both with or without jack.

[funkmuscle]

was thinking the same because LMMS was based on the original FL I think, right Paul?
I don't know how close you wanna get to that but something like FL studio is really needed for Linux..

[laba170]

anyway, my point is that there in principle aren't that big differences between FL studio and LMMS. Still I don't like LMMS, while I like Fl studio very much. It's all those small things that matter in the end. Like moving around in the piano roll by holding down the middle mouse button, being able to arrange patterns, automation and audio clips freely in the song editor etc. Best way to see what those small things are is by checking out FL studio. Also I didn't get the work flow of Lmms before trying FL studio for a while anyway. Maybe this is true for others too.

I've got one idea/thought btw.

In FL studio, you add generators and audio clips to the step sequencer, and then you may assign each generator/sample to a mixer track later. Wouldn't it be more logical if you instead added a generator/sample directly into the mixer, and then dragged it into the pattern? That way each pattern wouldn't be cluttered with generators not in use, as often happens in Fl studio. Of course, the mixer would be very cluttered, but having "mixer tabs" could help. Each one with its own master volume maybe. (Useful for drums?)

This is just some thoughts of course.

Also I'm a fan of seq24 and its pattern grid. Would be nice having
similar options in LMMS.

Being able to load hydrogen drum kits directly in some way would be neat too.

[funkmuscle]

well like Paul said, LMMS has faults that he's trying to fix. I like LMMS. was angry that it worked better on XP than on Linux but not anymore... Works way better on my arch box.
with soundfonts, we don't need hydrogen kits involved do we? I think the drum-tab editor would do fine but as Paul said, keep the ideas coming..

[brummer]

If you do not fit in any of the categories below, then just reply and say "Hi"

Hi

greats brummer

[studio32]

Hi,

JACK support!

I like the GUI ideas of the epichord and non-sequencer projects. And qtractor is also not bad, all though you have to open another midi edit window...

Maybe you can fork a project...

[spm_gl]

Connectivity, synchronisation and automation.
If you have a drum editor, please let the drums still come out on separate mixer tracks.
I need jack transport sync and mtc. And fully customizable midi bindings for automation. And jack in- and outputs for just about everything...

[StudioDave]

Hi Paul,

I'm glad to see this initiative, but I'm wondering about the original LMMS too. Will it continue as LMMS ? Will it still be available for Linux ?

Okay, on to my one suggestion :

JACK support, stable and without xruns at low-latency. JACK *is* the beating heart of Linux audio development, and that assertion has nothing to do with "modular vs non-modular". It has to do with the exceptional low-latency and stability JACK offers in a complex environment that includes 3D graphics (courtesy nVidia's evil binary driver) and high-performance audio software such as Ardour and Csound. Ah, what the heck, you've heard all this before now anyway.

And that's it from me. If LMMS performed well at low-latency I'm not sure what else I'd ask for. I agree with other posters that automation and improved MIDI controller binding would be nice. It is a pretty neat program, and it would be even neater if I could wire it directly into Ardour, sync'd via the JACK transport or maybe MTC.

Good luck, Paul. I'll be watching the project.

Best,

dp

[pgib]

Hi all,

Thanks for the first wave of responses! To answer a few specifics:

LMMS was based on the original FL I think, right Paul?
I don't know how close you wanna get to that but something like FL studio is really needed for Linux..

Correct it is based on FL. I agree something like FL Studio is needed. Unison's main goal is to be a better LMMS. Therefore, it will borrow many ideas from FL Studio. So, let me know if you have more specific recommendations, and I'll peruse FL, Seq24, and Epichord as well.

I suggest that you download the FL studio demo, It is very similar to LMMS, so you will be able to compare the two. Even though they look similar, Fl studio is a lot more polished of course.

Yeah, I should take another look. I used to use Fruity Loops when I was a Windows user, and I used FL Studio for a little while too after it came out. I can try out FL Studio again to get some ideas, but I would not be able to learn some of the really useful features unless I use FL Studio for a very long period of time (For example, the middle-click movement in the piano roll)

Wouldn't it be more logical if you instead added a generator/sample directly into the mixer, and then dragged it into the pattern? That way each pattern wouldn't be cluttered with generators not in use, as often happens in Fl studio. Of course, the mixer would be very cluttered, but having "mixer tabs" could help. Each one with its own master volume maybe. (Useful for drums?)

Yeah, good idea. One thing I've considered is that each Generator automatically gets a dedicated mixer channel. And as you point out Mixer Tabs/Groups can make this more manageable. I'll keep you Drag-n-Drop idea in mind.

we don't need hydrogen kits involved do we? I think the drum-tab editor would do fine

Probably don't want to have H2 kits involved directly, but.. with Proper JACK support, we could support "External Apps" better, "Add -> Generator -> External -> Hydrogen". Maybe that will spawn up a H2 instance and auto-connect to it? I really wish Lash/Ladish/Whatever would mature so session management is standardized.

Maybe you can fork a project...

Yeah, that is what is happening. I am borrowing code and design from several projects, so far I've taken a few ideas from Ardour, Ingen, LMMS, and QtCreator. There will be more down the road I'm sure This is actually one of the motivations for the name "Unison" to unify these other apps so I don't need 15 things open at the same time.

Connectivity, synchronisation and automation.
If you have a drum editor, please let the drums still come out on separate mixer tracks.
I need jack transport sync and mtc. And fully customizable midi bindings for automation. And jack in- and outputs for just about everything...

Yeah, I'm still trying to figure out how to best represent that. You have the case where one MIDI track should feed a single Generator (Maybe a Soundfont, or an external app like H2). Then you have other cases where a single MIDI track should feed multiple generators: Maybe you have a Bass-Drum synthesizer and 4 other drum Samples. I agree, there should be separate outputs in the case of the multiple generators.

But - How should the user say "MIDI Key #35 should play the Bass-Drum synthesizer", "MIDI Key #42 should play the High-hat sample". and to be able to group these... Is this just a specific case of "Layers" or "Track Groups"??

Could you please elaborate on "Customizable MIDI bindings for Automation?"

Hi Paul,
I'm glad to see this initiative, but I'm wondering about the original LMMS too. Will it continue as LMMS ? Will it still be available for Linux ?
...
If LMMS performed well at low-latency I'm not sure what else I'd ask for. I agree with other posters that automation and improved MIDI controller binding would be nice. It is a pretty neat program, and it would be even neater if I could wire it directly into Ardour, sync'd via the JACK transport or maybe MTC.

I'm glad you asked about LMMS. LMMS will remain LMMS - except that Toby (The original creator) will be pulling almost all the weight - which he has since the inception of it anyways. I'll still fix my bugs However, LMMS will probably never see a brand-new core, therefore, it will probably never see proper JACK support. That is where Unison comes in, I'm hoping to get Unison up to feature-parity with LMMS, and to move all the Generators to LV2. I imagine all LMMS users will move to Unison once someone, hopefully not me, writes an import-filter for LMMS Projects. Will Unison be called LMMS at that point? Who knows.. Unison will probably have a totally different name by that point, because users are already mistaking this for the Unison Filesystem Tool. FWIW, there was no drama to spark this - I've just be confined by LMMS's architecture.

JACK support is the name of the game it seems, from you and just about every other poster. Proper realtime support is required, and is one of the challenges that invoked me to start the project. You are the second person to mention "improved MIDI controller binding" Could you please elaborate? Also, what do you mean by automation? MIDI CC? or do you mean timing and transport automation? If you do mean CC (LMMS's Controllers) what would you change? LMMS's Controller support is already much like FL Studio's.

Thank you everyone for you ideas. Keep them coming! No idea is too small or too "dumb" to mention.

[superjoe]

Pasting snippets of an email conversation between me and pgib:

This is somewhat relevant:

http://linuxmusicians.com/viewtopic.php?f=28&t=2509

Something else to be addressed:

When playing back audio, you want to make sure that it is played back synchronized with time, even if it has a buffer underrun. For example, if you are recording something while playing back audio in the studio, you don't want little glitches to make the timing of your recording off.

http://flstudio.image-line.com/help/htm ... mixing.htm

The 0 dB reference level represents the loudest sound a digital audio file rendered from FL Studio can represent or the audio interface D/A converter can make, before clipping occurs. All peak meters in FL Studio turn orange or red to attract your attention when the signal exceeds 0 dB (see above). However, not all red peak meters (over 0 dB incidents) are bad.

Inside FL Studio, the audio is digital, and so, is a series of 32-bit floating point numbers. The Mixer is adding and subtracting numbers so that as the signal amplitude gets bigger, the numbers get bigger. The volume carried in tracks 1 to 99 (3) can be added to make any arbitrarily large number without clipping (there is nothing to clip). On the other hand, when the mix is sent to the outputs of your soundcard, or is rendered to a fixed bit-depth (e.g. 16 or 24-Bit), then clipping can happen.

As the Master mixer track (1) is the usual output to the 'physical world', you should not allow it to peak over 0 dB. The rest of the meters are merely guides to the relative volume in each track. Of course, if you have routed any Input Mixer tracks (7) directly to your soundcard outputs OR you are rendering mixer tracks to disk, then these too become 'real world' meters and must not exceed 0 dB.

It sounds like in FL Studio, the samples in mixer tracks are never clipped. Clipping only occurs when the master track is rendered. This makes fl studio much more usable than LMMS. How will this be attacked in Unison?

Over the next few weeks I'm going to design a gui layout on paper and then digitize it for everybody to critique.

[Louigi Verona]

Hey Paul!
Have mailed you my feedback quite some time ago, hope it was useful.

In general I would also advice you to try out FL Studio. I have used it for many years and in terms of user experience and usability it is very much polished. A lot of the disappointing things in LMMS are really usability issues. Even without JACK support, which is important, LMMS can do a lot, but many times usability is in the way of inspiration. I hope to be of use when early versions of Unison appear which I can test.

One thing which I have suggested since I switched to Linux and started to use LMMS, is to not have many generators (instruments) open, but instead just one, like in FL Studio. This allows the computer keyboard to know which instrument input to capture and same can be done with a midi keyboard (if no keyboard is explicitly chosen in instrument properties). It also allows you to avoid the situation of zillion windows open for no functional reason.

And, of course, routing in mixer, like in FL Studio, would add lots of functionality.

[laba170]

Yeah, I should take another look. I used to use Fruity Loops when I was a Windows user, and I used FL Studio for a little while too after it came out. I can try out FL Studio again to get some ideas, but I would not be able to learn some of the really useful features unless I use FL Studio for a very long period of time (For example, the middle-click movement in the piano roll)

You've also got access to the FL studio manual on their site. That's probably the quickest way to check out your "competition" anyway.

Yeah, good idea. One thing I've considered is that each Generator automatically gets a dedicated mixer channel. And as you point out Mixer Tabs/Groups can make this more manageable. I'll keep you Drag-n-Drop idea in mind.

Drag and drop in general is very nice, so I hope it'll be an option wherever it's possible.

To elaborate a little on that idea. Imagine you have an empty step sequencer set to pattern 1. Then you drag a generator from the browser into the step sequencer. Automatically, the generator is added to the "active generators" list in the browser, and creates it's own mixer channel. When you switch to pattern 2, the generator disappears. If you want to use the same generator(same mixer track and everything) again for pattern 2, you'll have to drag it from the "active generators" list in the browser.

In short, have each pattern only contain the generators it's actually using.

This might be a little inconvenient maybe, (compared to the FL studio approach) but we won't know before testing it of course. Still, it's more logical IMO.


And now some new ideas.


Using external generators:

Having simple midi out plugins, with "sub plugins" for each channel. (The main plugin creates a midi port in jack, and the sub plugins acts as generators) Sounds weird, but it seems more logical IMO than choosing the midi channel within the piano roll as in done in FL studio.


Incorporate the pattern grid from seq24:

First, imagine seq24. Then imagine seq24 with the browser from FL studio, and a step sequencer where each different patterns does not contain all generators. Let's say you want to create a simple tune with lead, bass, pad, and drums.

You find a lead synth in the browser, drag it to pattern 1, do the same for the other generators, (Bass synth -> pattern 2, pad synth -> pattern 3, ) and then drag all the drum samples you need to pattern 4.

Then you open pattern 3 in the step sequencer (right click menu in pattern grid?) edit the piano roll for the pad and create some basic chord progression. In pattern 4 , create a basic drumbeat just like you would in fl studio. Then you start looping, which should work just like in seq24 in the pattern grid. Selected patterns play over and over again.

open pattern 1, record a melody while looping
open pattern 2, add some bass...
And we're done!

Personally I love the seq24 approach, where you create a few simple"riffs" first in the pattern grid, (by looping a few long patterns) and then add details and arrange it in the song editor later.


After all, it's just about displaying the patterns in a grid. It shouldn't be to difficult. Can't say for sure though, since I'm no programmer.

Features I would like for the eventual pattern grid:

* Zooming with ctrl+mouse wheel, and moving around with mouse wheel pressed.

* Moving patterns around freely, so that they can be rearranged later

* Cloning patterns with ctrl+drag

* Information about the pattern shows up when hovering above it with the pointer. Like length, and a list of all used generators.

* This one is a bit difficult to explain, but imagine you have created a long pattern, and you want to create a new one consisting of only the the first notes. Then you should be able to show the pattern in a hovering window as if it was an audio clip, select the part you want (imagine selecting the first half of an audio clip) and ctrl+drag it into a free spot on the pattern grid.


Automation:

Actually I really like the ctrl+drag option in LMMS. To bad it seems the synth's must be integrated for it to work. Anyway, in fl studio if you want to automate vsti's, you find the vsti in the "current project" folder in the browser. There you can access midi-cc messages and parameters to automate. (right click -> create automation clip) Would be nice to have something similar in LMMS if the ctrl+drag option won't work.


step sequencer:

Maybe add a mixer track to the left, like the one in ardour? You select a generator within the pattern, and the mixer channel assigned to it appears within the step sequencer.