On 10/01/2014 10:46 PM, Marcin Nowak wrote: > Hello everyone, > > I'm a polish programmer and it's possible that I'll involve into > excellent LMMS project :)
Thanks and welcome! > Since some time I'm creating and developing my small app for music > production, far simplier than LMMS. I thought about bringing some > solutions from it to LMMS. I've found that those ideas make music > production (espiecially for classical, movie, epic genres) easier and > faster so I'd like to present and discuss them. > > --- PIANO-ROLL --- > > 1. Selecting all notes, but starting from indicated (by mouse). It's > very convenient if one wants to add (or remove) a note somewhere in > the middle of the track and must move part of notes to right or left. > My prog is doing such selection on clicking LBM on a note and holding > SHIFT. Sounds like a good idea. I can't remember if selection with shift pressed is already reserved for something though, but I'm sure there's some available key combinations. > 2. Changing note duration by mouse wheel. Unnecessary, there's already a feature for this: clicking a note, then holding shift and moving the mouse left/right. > 3. Quantization of note volume/panning/other parameters to values > which has already occured or to the grid (with constant steps). Sure, sounds good. Got any UI solutions in mind? > 4. Previewing notes of other tracks occuring at the same period of > time like the opened track. For example, notes of other > tracks/instruments would be unmodifiable, showed in another color, > alpha transparency etc. It helps making good harmony, prevents from > flickering from one track to another to align notes properly when > composing. It'd be a great feature that many editors lack... There > should be a possibility to turn showing 'alien' notes on/off, when > someone finds that there is too messy. Already been proposed as "ghost notes". Definitely worth implementing, but the UI can be tricky. How do you propose selecting the displayed "ghost pattern"? > 5. Chord recognition. Another cool point would be to make chord name > preview (like D Major, A# 9sus4) which is changing along with the song > cursor (I mean this little triangle showing current "time" above the > piano roll grid). This thing should distinguish chromatic instruments > from percussion etc. to properly find current chord. Musicans would be > proud. Cool, probably tricky to implement. We should probably start by displaying just the note name on hover, then move on to displaying whole chords. > 6. Chord parts indication. Once more, it's something which greatfully > helps in making good harmony, especially for classical pieces or some > film-like tracks. I'd add another button which turns on/off this > functionality. According to point no 4 it would provide valuable > information about what chord arises among many instruments (tracks) or > in the solely currently edited track. Not sure what exactly you mean here, but we already have a possibility to display scales on the piano roll. Isn't this kind of similar? > 7. Notes-grid colors. It's fine that we see piano keys on the left > side. IMO it'd be a bit 'finer' if black/white keys heights were > distinct in the grid. For example white key notes could lay on some > dark gray color while black key notes could have black background. It > would suggest C-Major scale (like we see on piano) and help in > recognizing intervals etc. Again we already have scale display functionality that can display any scale. > 8. Mods like filter cutoff, attack and release times, especially for > soundfont playback... We depend on fluidsynth for sf2 playback, so we can't use any DSP that fluidsynth doesn't support there. Unless someone codes an entirely new SF2 player from scratch, but that'd require a lot of work... For our native instruments, we already have filter cutoff, attack and release, which can all be automated. If you wanted to automate those per-note, that would require adding entirely new interfaces to the instrument API and would also be quite a big undertaking. Probably best left to the future when we're in a less volatile state (there's currently so much rehaul and reworking in core mechanics going on...) > --- PLAYBACK --- > > 9. When playing starts in the middle of the note, the playback is not > waiting for a next note to occur, but starting in the part of note(s). > My experience says that it also makes production easier. No, this probably won't happen. It's impossible to do for all instruments, and tricky even for the ones where it'd be theoretically possible. > Of course, mentioned things are only suggestions of TODOs and points > lacking to me in LMMS. If some points are good, why not to add them to > the official TODO-list? :) When I have time, I'd be really happy to > implement some of those. Feel free to say what do you think about it > and ask. New coders are always more than welcome. If you want to work on some specific new feature, please let us know beforehand so we can discuss and see how it fits our roadmap. Also, don't hesitate to ask if you have any questions about the codebase. It can be a bit messy at parts... ------------------------------------------------------------------------------ Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk _______________________________________________ LMMS-devel mailing list LMMS-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lmms-devel
