From: Thorsten W. <t_...@fr...> - 2006-03-13 21:05:09
|
Hi! Hearing of LMMS now and then made me curious and so I checked it out. A young project like this might be an oportunity for me as designer to make an impact, and so I promised Toby some ideas and a mockup. The mockup is still not finished and has not much to do with the current LMMS, so I don't even know if I should post it here or maybe on the LAD/U list (I asume most here are subscribed ther, too?). A bit of background: I'm an industrial designer interested in interface design. Some result of my work can be seen in Specimen and Om-synth. I used to work with Cubase VST. Currently I'm using MusE. _On_MDI_ My very first impression of LMMS was just a window management nightmare, but Cubase wasn't much better in that regard. The default MDI mode has all the usual problems: - Less options to make use of virtual desktops - Scrolled windows inside a scrolled window ... that's just not efficient. - Dead space eaten by the main window background. - Windowbars that don't match the native ones. - Always click to focus, ignoring the focus mode the user has chosen for the WM. - Own means of hiding/showing windows instead of relying on the WM, so the user can't take advantage of the training effect from always going the same way. I know some people like MDI, because they use it like a virtual desktop. But to be done right, it would have to be implemented on the WM level. Ok, so there's an option to go GIMP-like. The main window has a rather unfortunate format in that mode, but at least I get my beloved real WM windows with focus follows mouse :) _Plugins_ While I'm all for modularisation, the Unix philosophy and cross- application plugin formats, I have to say that the direct availability of the plugins and the common design of their windows is realy nice. Currently the strongest point of LMMS. _FL_Studio_ I collected screenshots of all the popular sequencers. LMMS looks so much and I guess is structured so much like FL Studio, it could result in mail from a lawyer. But I'm here to propose changes anyway :) _Remarks_ It took a while until I figured out how to add what I would call a instrument track (as opposed to a bb-editor track). Maybe you rely on drag&drop a bit much, maybe I'm just not used to this way. It's most confusing to me, that there's only one bb-editor, and patterns are shown based on selection from the song-editor. So the same plugins can be reused easily, but that could be done per routing instead. Having a mostly empty bb-editor and having to add tracks there to use separate plugins is not efficient. Removing/Adding steps in the bb-editor is rather useless as it is now. I hoped every track would be stretched to allow things like 12 over 16 steps, but the steps keep in sync, the longest track dictates the lenght. There needs to be a tempo and a meter track (allowing changes like going from 4/4 to 3/4), anyway. _Ideas_ As a designer, I like to put my work on a solid foundation. An elegant basic architecture, trying to make the most of the fewest elements. This makes the design manageable, should have similar effect regarding implementation and should lead to a consistent user experience. I think editing should become as similar as possible on song and pattern level. Patterns on the song-editor could be treated much like notes in a pattern. Instead of bb-editor tracks, you could have tracks that have a (sub-)sequencer as output. Empty patterns would trigger the default note, but you could use patterns with note content that would cause transposed and even polyphonic triggering. In short: MIDI Tracks could have MIDI-outs, synth-plugins or sequencers/ patterns as output/target. No specialisation on track level, but all those nice options. The bb-editor isn't much different from the song-editor. It's mainly a matter of resolution. It should be tried to reduce it to that. That would include a velocity parameter for patterns. Have I mentioned playing patterns from single MIDI keyboard keys, yet? ;) Cheers, Thorsten Wilms |
From: Tobias D. <tob...@gm...> - 2006-03-14 15:52:26
|
> _Plugins_ > > While I'm all for modularisation, the Unix philosophy and cross- > application plugin formats, I have to say that the direct availability > of the plugins and the common design of their windows is realy nice. > Currently the strongest point of LMMS. the problem is, that other plugin-formats (LADSPA, DSSI) etc. do not specif= y=20 anything conerning the GUI or use GTK, which doesn't help much, as LMMS is= =20 completely written using Qt. The plugin-API actually isn't that nice at it= =20 seems at a first view, but currently it does everything we need and=20 developing new plugins is quite easy by just taking an existing one and=20 modify it as needed... > _FL_Studio_ > > I collected screenshots of all the popular sequencers. LMMS looks so > much and I guess is structured so much like FL Studio, it could result > in mail from a lawyer. =46L guys already sent me a mail in which they they told me to remove the=20 graphics I really just copied from FL (which were actually only the=20 piano-keys in channel-window and piano-roll) and after discussing a while,= =20 they said: >> But if you have serious problems with LMMS looking partly similiar to FL >> Studio, please tell me, I really do not want to cause any trouble because >> of this. > > We don't have a problem with it. We just think/feel it's a pitty that an > obviously talented developer like you is copying images, concepts and > (what's even worse) mistakes we made 7 years ago. that's all ;-) they know they missed the opportunity to get on the=20 linux-market and now they have to accept, that free alternatives are coming= =20 up... > It took a while until I figured out how to add what I would call a > instrument track (as opposed to a bb-editor track). Maybe you rely > on drag&drop a bit much, maybe I'm just not used to this way. per default there's an instrument-track in the song-editor as well as in th= e=20 bb-editor, therefore you can use it as you like it... ok, the concept of=20 bb-tracks is not that obviously the first time, but after opening some=20 demo-songs and playing around with it, you'll figure this out quite fast I= =20 think. Beside that FL Studio uses the same concept and all users migrating = to=20 LMMS will just feel like home ;-) > It's most confusing to me, that there's only one bb-editor, and patterns > are shown based on selection from the song-editor. So the same plugins > can be reused easily, but that could be done per routing instead. Having > a mostly empty bb-editor and having to add tracks there to use separate > plugins is not efficient. you mean that there should be the possibility of opening several bb-editors= ,=20 each for a bb-track and then separate instrument-tracks for each bb-track? > Removing/Adding steps in the bb-editor is rather useless as it is now. > I hoped every track would be stretched to allow things like 12 over 16 > steps, but the steps keep in sync, the longest track dictates the > lenght. > There needs to be a tempo and a meter track (allowing changes like > going from 4/4 to 3/4), anyway. for the moment I would simply add a spinbox (or something like that) where = you=20 can specify the measure of your song. as everything will be automatable=20 later, you'll be able to automate these things as well... > I think editing should become as similar as possible on song and > pattern level. Patterns on the song-editor could be treated much like > notes in a pattern. Instead of bb-editor tracks, you could have tracks > that have a (sub-)sequencer as output. Empty patterns would trigger the > default note, but you could use patterns with note content that would > cause transposed and even polyphonic triggering. took me a while to understand this, but I think I got it ;-) no bad idea at= =20 all, I just currently don't know how to implement this. Probably I'm going = to=20 write a base-class for all tracks, having patterns inside. Then the=20 channelTrack-class (which is going to be renamed to instrumentTrack) is=20 derived from it as well as subSeqTrack and maybe someday some others... but= I=20 think we should discuss this before. > In short: MIDI Tracks could have MIDI-outs, synth-plugins or sequencers/ > patterns as output/target. No specialisation on track level, but all > those nice options. there's already MIDI-out-support in each instrument-track. > The bb-editor isn't much different from the song-editor. It's mainly > a matter of resolution. It should be tried to reduce it to that. > That would include a velocity parameter for patterns. you mean a global velocity-knob affecting the velocity/volume of all notes = of=20 this pattern? > Have I mentioned playing patterns from single MIDI keyboard keys, yet? ;) I think this is realizable very easy if we have the=20 "(sub-)sequencer-patterns" ;-) so far... toby =2D-=20 Man w=FCrde viel Almosen geben, wenn man Augen h=E4tte zu sehen, was eine empfangende Hand f=FCr ein sch=F6nes Bild macht. -- Johann Wolfgang von Goethe (Maximen und Reflexionen) |
From: Thorsten W. <t_...@fr...> - 2006-03-14 19:50:09
|
On Tue, Mar 14, 2006 at 04:52:16PM +0100, Tobias Doerffel wrote: > the problem is, that other plugin-formats (LADSPA, DSSI) etc. do not specify > anything conerning the GUI or use GTK, which doesn't help much, as LMMS is > completely written using Qt. The plugin-API actually isn't that nice at it > seems at a first view, but currently it does everything we need and > developing new plugins is quite easy by just taking an existing one and > modify it as needed... Both LADSPA and DSSI are toolkit agnostic, because the linux audio developers can't decide on a single toolkit and no one was like trying to dictate one. The sequencers MusE and Rosegarden should be a nice examples of QT based LADSPA hosts. Rosegarden also supports DSSI, which is still only in CVS for MusE. Theres a _huge_ wealth of LADSPA plugins. Wanting to reimplement even a subset would be a rather silly endevour. There's always the option to add specific GUIs for important LADSPAs instead of always using a generic one. MusE has its own internal softsynth plugin standard, called MESS, or something like that. Just to have more control than DSSi would allow, as far as I know. This all doesn't mean LMMS can't have its own plugin format. > > We don't have a problem with it. We just think/feel it's a pitty that an > > obviously talented developer like you is copying images, concepts and > > (what's even worse) mistakes we made 7 years ago. Well, I would agree with them. > that's all ;-) they know they missed the opportunity to get on the > linux-market and now they have to accept, that free alternatives are coming > up... What _market_? ^^ > > It's most confusing to me, that there's only one bb-editor, and patterns > > are shown based on selection from the song-editor. So the same plugins > > can be reused easily, but that could be done per routing instead. Having > > a mostly empty bb-editor and having to add tracks there to use separate > > plugins is not efficient. > you mean that there should be the possibility of opening several bb-editors, > each for a bb-track and then separate instrument-tracks for each bb-track? I just expected a 1:1 mapping between bb tracks and bb-editors. The current parallelism is quite strange. My proposal below boils down to having only one kind of song/pattern editor, just used on different levels anyway. So current bb tracks would just be tracks with empty patterns on them to trigger a sub-pattern like explained already. > took me a while to understand this, but I think I got it ;-) no bad idea at > all, I just currently don't know how to implement this. Probably I'm going to > write a base-class for all tracks, having patterns inside. Then the > channelTrack-class (which is going to be renamed to instrumentTrack) is > derived from it as well as subSeqTrack and maybe someday some others... but I > think we should discuss this before. Deriving subSeqTrack? Idealy there should be no special case at all. Lets see ... we could have - Sequencers. - Sequencers have Tracks - Tracks have Input and Output bound to them (lets call the things connected to I/O Sources(sending) and Sinks(receiving)) - Patterns are placed on Tracks. It could be allowd to place more than one Pattern on a Track in paralell (it would be handled much like stereo/multi- channel audio on audio tracks. - Each Pattern has a Velocity value, because the Pattern, if empty, can be used like a single note to a Sequencer sink. For empty Patterns, the default note of the Sequencer will be used. For non-empty Patterns, the contained notes are used instead. The playback of the Sequencer will be transposed and can be polyphonic, then. - For a pino-roll, a Sequnecer would have 128 tracks mapped to MIDI notes. Ooh, I'll have to think more about this. > there's already MIDI-out-support in each instrument-track. MIDI outs should be offered on the same level as plugins. Since it's quite likely the user wants to feed a track into either a plugin _or_ a MIDI out. Then again, layering should be possible. One reason why a patchbay would be nice. The Om-synth engine could provide LADSPA/DSSI support _and_ MIDI and audio routing. > > The bb-editor isn't much different from the song-editor. It's mainly > > a matter of resolution. It should be tried to reduce it to that. > > That would include a velocity parameter for patterns. > you mean a global velocity-knob affecting the velocity/volume of all notes of > this pattern? Not directly. A velocity value like every note has one. Adjustable in the same way (bars below the note grid or scrollwheel). A plugin receiving data from the track would be free to ignore it, or to use it as factor on all contained velocities (127 = 100%). > > Have I mentioned playing patterns from single MIDI keyboard keys, yet? ;) > I think this is realizable very easy if we have the > "(sub-)sequencer-patterns" ;-) That's one of my points :) --- Thorsten Wilms |
From: Lucas <lmm...@mi...> - 2006-03-14 21:28:58
|
>> that's all ;-) they know they missed the opportunity to get on the >> linux-market and now they have to accept, that free alternatives are coming >> up... > > What _market_? ^^ > > --- > Thorsten Wilms Well, personally, the main reason I still use Windows as my main desktop OS is because Fruityloops only runs on it, and I don't feel like rebooting every time I have an idea. Quite a bunch of people I know are tied to windows for the exact same reason, FL won't run on Linux. So having a program that has a similar work-flow would no doubt attract quite some current FL users. By the way, I recently tried LMMS on a powerbook running debian (I compiled a cvs checkout), and it segfaulted on startup (except the first time, where it configured, then segfaulted). I'll try it again soon, cause when I checked out there were a lot of big features added. If it still segfaults, I'll give debugging a try. Lucas |
From: danny m. <khj...@ya...> - 2006-03-14 22:27:59
|
> By the way, I recently tried LMMS on a powerbook > running debian (I compiled a cvs checkout), and it > segfaulted on startup (except the first time, where > it configured, then segfaulted). It runs ok on my powerbook, but I have a similar problem on my amd64 machine. I haven't tracked down why it's happening yet, but where it happens is at lines 437 and 518 in setup_dialog.cpp. m_audioInterfaceSetupWidgets[eng()->getMixer()-> audioDevName()]->show(); m_midiInterfaceSetupWidgets[eng()->getMixer()-> midiClientName()]->show(); Commenting those two lines out gets past the segfault for me. Danny __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com |
From: Bengt <be...@su...> - 2006-03-15 07:57:27
|
tisdagen den 14 mars 2006 20.49 skrev Thorsten Wilms: > > > We don't have a problem with it. We just think/feel it's a pitty that > > > an obviously talented developer like you is copying images, concepts > > > and (what's even worse) mistakes we made 7 years ago. > > Well, I would agree with them. I've never worked with FL so I would like to here about what misstakes they= =20 are refering to. > > that's all ;-) they know they missed the opportunity to get on the > > linux-market and now they have to accept, that free alternatives are > > coming up... > > What _market_? ^^ Are you saying that there is no linux-market? I wonder where my money went. =2D-=20 /bengan |
From: Thorsten W. <t_...@fr...> - 2006-03-15 08:57:04
|
On Wed, Mar 15, 2006 at 08:56:57AM +0100, Bengt G?rd?n wrote: > > What _market_? ^^ > > Are you saying that there is no linux-market? I wonder where my money went. No. But I think there's hardly a market for a sequencer on Linux, at least, if you try to make money the usual way via selling licences to a closed source app. There might be a few people who would pay for such a thing. But then you still have distribution and version compatibility problems. --- Thorsten Wilms |