From: Tobias D. <tob...@gm...> - 2008-03-16 15:05:14
|
Hi all, LMMS 0.4.x is evolving very well, has gotten quite stable and currently is being filled with a lot new cool features. I want to give a short overview of what's done so far and what is planned to be done until 0.4.x release. M/V-split is 99% complete. Singerbot and VST-effect-hoster-plugin are missing but will be splitted somewhen when I'm idle ;-) The results of M/V-split are exactly the way we hoped them to be. First of all there's a great improvement in project-loading-time which of course also improves performance when rendering a project from command-line. Listening to presets by clicking them also works faster now. Instrument-track-windows are being created on-demand - this could be extended in future. Rendering without X(11) is almost complete - what's left is the rendering-process which needs to be splitted out of the progress-window. We'll see what other cool things will be realizable using M/V-architecture. Paul added a very cool new plugin which allows to use SoundFont2-files within LMMS which will make LMMS even more interesting for semi-professional users. As you've probably already heard, LMMS 0.4.x will be fully SMP-capable by introducing worker-threads according to the number of cores detected. The rendering-load (instrument- and effect-processing) is being distributed amongst those threads. This works quite well after some work on core-classes has been done to make them reentrant (for example the sampleBuffer-class) and on my dual-core-system it scales up to 1.7 - the rest is non-parallelizable "overhead". Anyways it's a great improvement - even more on quadcore-systems (I at least expect up to 3.0x but can't test)! Very recently I added the long-requested effect-mixer with 64 FX-channels - you can add arbitrary effects to each individual FX-channel. Per default instruments are being routed into master (FX 0) but you can easily change that using the ominous LCD-Spinbox which existed for ages but never made any sense at all. The FX-mixer completes LMMS' core tools for easy music-production. Please note that the current FX-mixer-implementation is far from being complete - neither the GUI nor the functionality! It's just a first proof-of-concept being made up quickly. Another fundamental change will be a new internal resolution of 192th instead of 64th allowing triplet-notes as well as other time-signatures than 4/4. Hurray for all non-techno-song-writers! :) There were several contributions to the artwork-contest. Thanks to all submitters! However Fabi is the only one who made up a complete, consistent and modern theme for all plugins. So I consider him to be the winner. Congratulations! I already mailed with him to get things integrated. Some changes will be neccessary to the plugins, that's why nothing of this has changed in SVN yet. I'm looking forward to have this new artwork integrated within next few weeks. All those improvements so far are nice but I'd also like to make some basic changes to LMMS' UI and the way you work with it. Now that the FX-mixer has been added and one will use even more effects, there're so many big and small windows floating around in LMMS' workspace (song-editor, BB-editor, FX-mixer, project-notes, 1-2 instrument-track-windows, 3-4 FX-control-windows ...) which is simply not usable anymore as you always have to get overlapping windows back into front, move some, close others, scroll here, scroll there .... Personally I'd love to have a dock-based approach like it can be seen in recent Hydrogen-versions. Qt4 offers quite nice support for this but I still do not know how to organize the GUI with such a concept. You can't have that much windows open so we need intelligent ideas how to quickly switch between views so that one still can work smoothly. The upper toolbar and the song-editor are very likely to be merged to save space and make things easier. Starting from the middle to the bottom of the screen I imagine there could be an "editor-view" with some tabs at the top - choosing between BB-editor, piano-roll, automation-editor and project-notes-editor. Choosing an according action somewhere (e.g. clicking a pattern, a BB-item or "Open in Automation-Editor") will automatically switch the editor-view. But what to do with FX-mixer, instrument-track-windows, FX-control-dialogs ...? We need your ideas! Everybody who has some good ideas is asked to share them with us and maybe also make up some mockups. Hoping for a good discussion :) toby |
From: Tobias D. <tob...@gm...> - 2008-03-17 08:49:12
Attachments:
dock-mockup.png
|
Am Monday, 17. März 2008 05:32:35 schrieb Paul Wayper: > Isn't it already? How does it work in 0.3? For sure not. > I can set LMMS to have two > processors and it seems to use both cores to render a track - I can get up > to about 175% CPU usage across two procesors, so I suppose I'm getting > about the same results you are. Maybe that's because of excessive GUI-thread-usage i.e. screen-updates/animatins. The render-process itself will always only take max. 100% in 0.3.x > Well, I like the idea of an 'editor' window just changing behaviour, but > it's definitely handy to be able to view a rhythm, a piano roll and an > automation side by side, so to speak. Why? Anyways it looks like we can satisfy this requirement too, see below. > Likewise, it'd be really good if one > could see two piano rolls simultaneously to compare timing of notes. hm one could add a split-view (like in Konqueror) to have to patterns open in one piano-roll. Having two piano-rolls is a bad idea in my eyes. > One idea I'd suggest is to make ctrl-tab more like alt-tab. At the moment > (on 0.3.2) it just cycles through the windows but seems to go off through > 16 or so invisible windows before going through the list again. It'd be > nice to see a list of windows, and reorder them so that the most recently > used window was put next in the queue. The new dock-interface will make this obsolete I think ;-) > But I'm interested in this 'dock' idea - can you explain that a little > further? See http://doc.trolltech.com/4.3/mainwindows-dockwidgets.html - on the right side there're 2 dock-widgets. You can move, resize, close and undock them. Furthermore several docks can be stacked onto each other so that a tab-bar is displayed where you can switch between the docks. Beside that search for "qt dock widget" at google picture-search and you'll see further examples of what's meant. Said that the editor-window could have several tabs for the editors - by dragging a tab to somewhere you can undock the editor or move it to somewhere else as normal dock. The attached mockup shows a basic idea for the new GUI. toby |
From: Paul G. <dr...@gm...> - 2008-03-17 09:05:58
|
Cool. I had a related idea for the instrument plugins.. Maybe they can all be in one Horizontal scroll-pane. The instrument views can be expanded or collapsed. When collapsed, it is just a vertical sliver (16-32 pixels wide) with the name, instrument type, and maybe a control or two like volume and fx channel. The current Instrument is always shown expanded, but the user can expand more instruments if they choose. The Instruments can also be collapsed, reordered, and maybe even have features for grouping based on instrument type, or sorting to match the order of the songEditor. Maybe we have artwork for the collapsed instruments to make the different instrument types more distinguishable. Basically, it would be like Reason's rack, except horizontal, and more compact/simple. The benefits are: Instrument "windows" are grouped together. Provides a smooth manner of organizing and managing instruments. Similar to tabs, but allows the user to have more than one expanded. I can draw a mock-up if you would like. Let me know what you think -Paul On Mon, Mar 17, 2008 at 4:34 AM, Tobias Doerffel <tob...@gm...> wrote: > Am Monday, 17. März 2008 05:32:35 schrieb Paul Wayper: > > > Isn't it already? How does it work in 0.3? > For sure not. > > > > I can set LMMS to have two > > processors and it seems to use both cores to render a track - I can get up > > to about 175% CPU usage across two procesors, so I suppose I'm getting > > about the same results you are. > Maybe that's because of excessive GUI-thread-usage i.e. > screen-updates/animatins. The render-process itself will always only take > max. 100% in 0.3.x > > > > Well, I like the idea of an 'editor' window just changing behaviour, but > > it's definitely handy to be able to view a rhythm, a piano roll and an > > automation side by side, so to speak. > Why? Anyways it looks like we can satisfy this requirement too, see below. > > > > Likewise, it'd be really good if one > > could see two piano rolls simultaneously to compare timing of notes. > hm one could add a split-view (like in Konqueror) to have to patterns open in > one piano-roll. Having two piano-rolls is a bad idea in my eyes. > > > > One idea I'd suggest is to make ctrl-tab more like alt-tab. At the moment > > (on 0.3.2) it just cycles through the windows but seems to go off through > > 16 or so invisible windows before going through the list again. It'd be > > nice to see a list of windows, and reorder them so that the most recently > > used window was put next in the queue. > The new dock-interface will make this obsolete I think ;-) > > > > But I'm interested in this 'dock' idea - can you explain that a little > > further? > See http://doc.trolltech.com/4.3/mainwindows-dockwidgets.html - on the right > side there're 2 dock-widgets. You can move, resize, close and undock them. > Furthermore several docks can be stacked onto each other so that a tab-bar is > displayed where you can switch between the docks. Beside that search for "qt > dock widget" at google picture-search and you'll see further examples of > what's meant. > > Said that the editor-window could have several tabs for the editors - by > dragging a tab to somewhere you can undock the editor or move it to somewhere > else as normal dock. The attached mockup shows a basic idea for the new GUI. > > toby > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Lmms-users mailing list > Lmm...@li... > https://lists.sourceforge.net/lists/listinfo/lmms-users > > |
From: Paul G. <dr...@gm...> - 2008-03-17 18:33:56
|
Here is a mockup of my idea. This "Scroll area" could very well be nested into a pane. http://lmms.sourceforge.net/test/instrumentPanelMock.tar.bz2 1) Project has one instrument: Triple Oscillator 2) User adds an LB302, notice how it is placed next to the Triple Oscillator 3) User adds Vibed, but it is clipped by the side of the scroll area 4) User scrolls to the right to expose all of Vibed 5) User collapses both TripleOscillator and the LB-302. Some standard instrument controls are shown at the top. Artwork makes it easy to distinguish the different collapsed plugins. The only thing missing from this drawing is some sort of activity-indicator (maybe an LED?) to allow the user to see instrument activity without using the piano. 6) User adds another TripleOscillator and then switches to the ENV/LFO view. Notice how two instruments can still be expanded in harmony, even with different tabs shown. 7) User decides to collapse the second TripleOscillator I hope this makes the idea easier to understand. -Paul On Mon, Mar 17, 2008 at 5:05 AM, Paul Giblock <dr...@gm...> wrote: > Cool. I had a related idea for the instrument plugins.. Maybe they > can all be in one Horizontal scroll-pane. The instrument views can be > expanded or collapsed. When collapsed, it is just a vertical sliver > (16-32 pixels wide) with the name, instrument type, and maybe a > control or two like volume and fx channel. The current Instrument is > always shown expanded, but the user can expand more instruments if > they choose. The Instruments can also be collapsed, reordered, and > maybe even have features for grouping based on instrument type, or > sorting to match the order of the songEditor. Maybe we have artwork > for the collapsed instruments to make the different instrument types > more distinguishable. Basically, it would be like Reason's rack, > except horizontal, and more compact/simple. The benefits are: > Instrument "windows" are grouped together. Provides a smooth manner > of organizing and managing instruments. Similar to tabs, but allows > the user to have more than one expanded. > > I can draw a mock-up if you would like. Let me know what you think > > -Paul > > > > On Mon, Mar 17, 2008 at 4:34 AM, Tobias Doerffel > <tob...@gm...> wrote: > > Am Monday, 17. März 2008 05:32:35 schrieb Paul Wayper: > > > > > Isn't it already? How does it work in 0.3? > > For sure not. > > > > > > > I can set LMMS to have two > > > processors and it seems to use both cores to render a track - I can get up > > > to about 175% CPU usage across two procesors, so I suppose I'm getting > > > about the same results you are. > > Maybe that's because of excessive GUI-thread-usage i.e. > > screen-updates/animatins. The render-process itself will always only take > > max. 100% in 0.3.x > > > > > > > Well, I like the idea of an 'editor' window just changing behaviour, but > > > it's definitely handy to be able to view a rhythm, a piano roll and an > > > automation side by side, so to speak. > > Why? Anyways it looks like we can satisfy this requirement too, see below. > > > > > > > Likewise, it'd be really good if one > > > could see two piano rolls simultaneously to compare timing of notes. > > hm one could add a split-view (like in Konqueror) to have to patterns open in > > one piano-roll. Having two piano-rolls is a bad idea in my eyes. > > > > > > > One idea I'd suggest is to make ctrl-tab more like alt-tab. At the moment > > > (on 0.3.2) it just cycles through the windows but seems to go off through > > > 16 or so invisible windows before going through the list again. It'd be > > > nice to see a list of windows, and reorder them so that the most recently > > > used window was put next in the queue. > > The new dock-interface will make this obsolete I think ;-) > > > > > > > But I'm interested in this 'dock' idea - can you explain that a little > > > further? > > See http://doc.trolltech.com/4.3/mainwindows-dockwidgets.html - on the right > > side there're 2 dock-widgets. You can move, resize, close and undock them. > > Furthermore several docks can be stacked onto each other so that a tab-bar is > > displayed where you can switch between the docks. Beside that search for "qt > > dock widget" at google picture-search and you'll see further examples of > > what's meant. > > > > Said that the editor-window could have several tabs for the editors - by > > dragging a tab to somewhere you can undock the editor or move it to somewhere > > else as normal dock. The attached mockup shows a basic idea for the new GUI. > > > > toby > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Lmms-users mailing list > > Lmm...@li... > > https://lists.sourceforge.net/lists/listinfo/lmms-users > > > > > |
From: Paul G. <dr...@gm...> - 2008-03-18 20:44:15
|
Yes, but it must be an option in the "Save As.." dialog. If you are working on your own projects, you certainly do not want tons of copies of the same files. Especially with the SoundFont player in 0.4. Some soundfonts are around 100MB. Nobody wants duplicate copies of that, or to have to download the soundfont hundreds of times. -Paul On Tue, Mar 18, 2008 at 4:09 PM, enzo kay <dar...@gm...> wrote: > I agree with kevin's ideia and his scheme or diagram. I think it's the best > way > to join the project and it's samples together. > > > > > > > On Tue, Mar 18, 2008 at 7:29 PM, Kevin Cao <kev...@gm...> wrote: > > > Hi, > > I'm also using a software called Renoise. Song files are stored in a > *.xrns file which contains a XML document and SampleData directory where all > samples of the song are stored : > > > > mysong.xrns > > |---Song.xml > > |---SampleData > > |---Instrument00 (name00) > > |--- [...] > > |---InstrumentXX (nameXX) > > |---Sample00 (name00).flac > > |--- [...] > > |---SampleXX (nameXX).flac > > > > So +1 for this idea, it's very useful when you don't work alone. > > > > Looking forward to see the 0.4 ;) > > > > .kev > > > > > > 2008/3/18, Paul Giblock <dr...@gm...>: > > > > > > > > > Here is a message that was sent to me instead of the discussion. Enzo > > > - Make sure to do "Reply all" then delete any names that are not > > > lmms-devel or lmms-users. > > > > > > Sounds like an interesting idea. I imagine we could store the > > > external files into the XML as base64, but it would be ideal to > > > realize this without requiring a rewrite of the instruments. I guess > > > the project saver can make a second pass, and add an additional > > > attribute to each tag that contains a file name.. I dunno. > > > > > > -Paul > > > > > > ---------- Forwarded message ---------- > > > From: enzo kay <dar...@gm...> > > > Date: Tue, Mar 18, 2008 at 6:34 AM > > > Subject: Re: [Lmms-users] Current state of 0.4.x and general UI-design > questions > > > To: pg...@gm... > > > > > > > > > People I have an ideia. I think it's a necessity to everone. > > > I think that adding a packing way for the projects > > > something like Fl studio zip files so that anyone could > > > hear another ones project will all sounds > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Lmms-users mailing list > Lmm...@li... > https://lists.sourceforge.net/lists/listinfo/lmms-users > > |
From: mass_konfuzion <lh...@gm...> - 2008-04-07 03:07:19
|
Hi all, I know I've been MIA lately--I've been busy with work, but I'm re-prioritizing my time and activities, so I'm back. As a refresher, I'm primarily a Windows & FL Studio user; I often compare features of LMMS to FL Studio... sorry :-/ . But I've been dabbling with Linux & LMMS, and I think it's awesome. Here's a UI idea/suggestion that I haven't seen in any of the music software I've used, but is standard practice all over the internet: Add the ability to "tag" samples (e.g. wav files, mp3 clips, etc), similar to blog tagging. It would be cool to be able to browse samples based on their tags, rather than (or maybe in addition to) their actual location. This would allow easier sample library management. Picture this: Instead of trying to organize samples into folders and subfolders, e.g. "drums/bass_drums", "drums/snare_drums", etc, the user could tag a snare drum as a "drum" and a "snare". Then, the sample browser could display the tags, rather than folder names. This would allow a user to dump all of their stuff into one folder on the computer, but still "organize" samples by type, kit name, affiliation with a specific project (e.g. if you used a particular vocal sample specifically for a song, you could tag it as a "vocal" and as part of "example project #1"), etc. Perhaps the same sample might show up in more than one place in the sample browser, but that's not necessarily a problem. Technically, I think this could be implemented with a simple metadata file that would store the sample's file name, location, tags, and maybe even a nickname--overhead of only a few bytes per file. Perhaps LMMS could search and index user-specified folders to create the metadata files, and/or users could specify them by hand. I'd be willing to work on this piece, but I'd need some help. I used to be a wizard, but I haven't coded in C or C++ heavily for about 2.5 years. I've done some Python and php, so I haven't exactly forgotten syntax, but algorithms and C/C++ dirty details/nuances are fuzzy for me. Thoughts? -- View this message in context: http://www.nabble.com/Current-state-of-0.4.x-and-general-UI-design-questions-tp16079969p16532806.html Sent from the lmms-devel mailing list archive at Nabble.com. |
From: Paul G. <dr...@gm...> - 2008-04-07 04:36:29
|
That's a pretty interesting idea. One question that comes to mind is, how are the files referenced from within the project? filenames? md5 sum? Anyways, cool none-the-less. If you want to get your hands dirty with some C++, maybe you can help move knobs and stuff around for the new artwork? Check out the roadmap/TODO for some other things. Pretty trivial task, but should cover most of the fundamental stuff. Good to hear from you, Paul On Sun, Apr 6, 2008 at 11:07 PM, mass_konfuzion <lh...@gm...> wrote: > > Hi all, I know I've been MIA lately--I've been busy with work, but I'm > re-prioritizing my time and activities, so I'm back. As a refresher, I'm > primarily a Windows & FL Studio user; I often compare features of LMMS to FL > Studio... sorry :-/ . But I've been dabbling with Linux & LMMS, and I think > it's awesome. Here's a UI idea/suggestion that I haven't seen in any of > the music software I've used, but is standard practice all over the > internet: Add the ability to "tag" samples (e.g. wav files, mp3 clips, > etc), similar to blog tagging. > > It would be cool to be able to browse samples based on their tags, rather > than (or maybe in addition to) their actual location. This would allow > easier sample library management. > > Picture this: Instead of trying to organize samples into folders and > subfolders, e.g. "drums/bass_drums", "drums/snare_drums", etc, the user > could tag a snare drum as a "drum" and a "snare". Then, the sample browser > could display the tags, rather than folder names. This would allow a user > to dump all of their stuff into one folder on the computer, but still > "organize" samples by type, kit name, affiliation with a specific project > (e.g. if you used a particular vocal sample specifically for a song, you > could tag it as a "vocal" and as part of "example project #1"), etc. > Perhaps the same sample might show up in more than one place in the sample > browser, but that's not necessarily a problem. > > Technically, I think this could be implemented with a simple metadata file > that would store the sample's file name, location, tags, and maybe even a > nickname--overhead of only a few bytes per file. Perhaps LMMS could search > and index user-specified folders to create the metadata files, and/or users > could specify them by hand. > > I'd be willing to work on this piece, but I'd need some help. I used to be > a wizard, but I haven't coded in C or C++ heavily for about 2.5 years. I've > done some Python and php, so I haven't exactly forgotten syntax, but > algorithms and C/C++ dirty details/nuances are fuzzy for me. > > Thoughts? > -- > View this message in context: http://www.nabble.com/Current-state-of-0.4.x-and-general-UI-design-questions-tp16079969p16532806.html > Sent from the lmms-devel mailing list archive at Nabble.com. > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Register now and save $200. Hurry, offer ends at 11:59 p.m., > Monday, April 7! Use priority code J8TLD2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > _______________________________________________ > LMMS-devel mailing list > LMM...@li... > https://lists.sourceforge.net/lists/listinfo/lmms-devel > |
From: Paul W. <pa...@ma...> - 2008-04-08 05:26:45
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 mass_konfuzion wrote: | It would be cool to be able to browse samples based on their tags, rather | than (or maybe in addition to) their actual location. This would allow | easier sample library management. This is a really good idea. I'd also keep the 'traditional' folder-based approach, which is much nicer than other 'drop-down list' style interfaces I've seen in other software. | Picture this: Instead of trying to organize samples into folders and | subfolders, e.g. "drums/bass_drums", "drums/snare_drums", etc, the user | could tag a snare drum as a "drum" and a "snare". Then, the sample browser | could display the tags, rather than folder names. This would allow a user | to dump all of their stuff into one folder on the computer, but still | "organize" samples by type, kit name, affiliation with a specific project | (e.g. if you used a particular vocal sample specifically for a song, you | could tag it as a "vocal" and as part of "example project #1"), etc. | Perhaps the same sample might show up in more than one place in the sample | browser, but that's not necessarily a problem. As well as storing user-supplied tags, tagging by (optionally recognised) words in filenames and pathnames would be another way to populate this information. | Technically, I think this could be implemented with a simple metadata file | that would store the sample's file name, location, tags, and maybe even a | nickname--overhead of only a few bytes per file. Perhaps LMMS could search | and index user-specified folders to create the metadata files, and/or users | could specify them by hand. OGG and MP3 both allow storage of metadata in the file itself. If you wanted to, you could store some of this metadata in extended filesystem attributes (also copied around when file is copied) or in a (e.g) .$filename.lmms_metadata file in the same directory. As an aside, it would be nice to see the metadata of the file in a tooltip when you hover over the file. | I'd be willing to work on this piece, but I'd need some help. I used to be | a wizard, but I haven't coded in C or C++ heavily for about 2.5 years. I've | done some Python and php, so I haven't exactly forgotten syntax, but | algorithms and C/C++ dirty details/nuances are fuzzy for me. I've been talking to Paul Giblock and am going to start on an epic voyage of discovery by adding Doxygen documentation to the code. What I'll be adding is as much as my non-C++ coder brain can understand, and it'll be up to the developers to fix this (for simplicity, I'll put DONE marks in where I *have* managed to document it fully, and the developers can then edit everything else). This should make it easier for newer developers to get into the code. I'd recommend hanging out on the ##lmms channel on irc.freenode.org and asking questions there - Paul or Tony or I are usually on there. Have fun, Paul -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFH+wILu7W0U8VsXYIRAvaeAKCIzJkcNMVGRRfrafXpUIKlV0GY0wCfbIT+ TmiIIp0VNCfybbIoB36fkkc= =kBNN -----END PGP SIGNATURE----- |
From: J. F. S. <tr...@gm...> - 2008-04-10 21:44:40
|
Hi all, i'm not a C++ developer at all, but i can understand the synthax more or less (i'm a C programmer). So, if "moving knobs" is a matter of place things in the GUI and/or it's just a "mechanical" work, i think i could do that with a bit of help (mostly with the toolchain and the very first steps). I've never used Qt, but i know a bit of Gtk and Juce (well, and a little visual c++). And if you need some retouch on graphics just tell me :) Seeya, fabi. |