[LMMS-devel] Hello, everyone!

[William L. <xfu...@gm...>]

Hello, I'm a long-time FL user who has been waiting for LMMS to be usable
for all the music I make with FL and having just recently checked it out
(after finding it not ready a year or two ago) I'm extremely impressed at
the progress. VSTs, though slow-to-load, seem to work almost flawlessly here
on my Ubuntu box, FLP importing hasn't crashed yet, and the overall
performance of the application is much better than the last time I played
around with it.

That being said, there's a number of itches to scratch before I can totally
dump FL and use this great software. Luckily I'm also a C++ programmer, so
I've decided to write some code.

-

VSTs are working quite nicely, but there is currently no way to control
multi-input VSTs such as the EDIROL Orchestral plugin (which uses all 16 of
the inputs for different orchestra instruments). I do a lot of compositions
using this VST so I've started to implement this.

I've extended the 'note' class to keep track of the channel the note is tied
to, and added a new button to the piano roll toolbar which displays a color
for it's icon. Clicking it gives you a menu of the 16 inputs (each have
colors which are provided by the current LmmsStyle).

Normally when notePlayHandle sends the midi out events for NoteOn, NoteOff,
Volume etc, it uses the midi output channel configured in the
InstrumentTrack's MidiPort. I changed this to use the new channel getter of
the 'note' type, and added a check for outputEnabled() on the midi port to
change the port to the output port (so it's either/or).

I don't think this makes sense though. I don't really understand why all
instrument plugins *have* midi out ability. In FL studio afaicr you could
use a special Midi Out instrument, and any instrument could take midi *in*.
The question with LMMS' setup is: when midi out is enabled, do we duplicate
the events to send out so that the VST (or other instrument) gets the events
*as well as* whatever controller listens on the midi-out port, or don't send
the events to the VST (which would seem silly). Either way, with the
exception of chaining instruments or reusing the midi data from the VST for
some other purpose, it doesn't seem that useful.

Apart from hearing from you guys on how that situation should be handled, my
changes toward this goal are almost complete. One of the last things to do
is update the FLP import to support multiple notes, but I'm not sure how
well that will turn out (I'm guessing the FLP documentation isn't very nice,
but so far a lot of the bits needed for what I've done were there, but not
hooked up yet) so we'll see. I have some other obligations but I should
tentatively be able to deliver a patch in a week or so.

Another feature I'm hoping to look into is that to get the step sequencer to
be capable of making beats longer than a single measure. Changing the time
signature currently changes the amount of beats in a beat pattern but that's
not really a solution.

-

Finally there are some general bugs I'd like to try to fix (or at least
point out). Both the stable version I got from Canonical's repos and the
latest git have an issue which causes clicks on the inner window borders to
not update Z layering, so you can move and interact with the window but it
will not raise above any other inner windows.

Also, the shading which is supposed to indicate beats per measure on the
step sequencer is static, so when the time signature is changed, it does not
update to use groups of 3 or whatever you have selected.

One more: when you use the File menu when the shiny new get started screen
is shown (nice, btw), sometimes that screen will not be hidden when it
should. I don't know about File->Open, but File->Import shows this behavior
(I'm guessing that stuffs pretty new though, so I wouldn't expect it to be
perfect and it's very minor.

I'm excited to help with this project! Any advice/gotchas or pointers to
extended documentation on the underlying architecture of LMMS would be
appreciated. I scanned the wiki but I see the documentation is mostly
related to using it and getting started with development rather than
documenting the system architecture (well I guess I could help with that too
:-D)

-- 
rezonant

long name: William Lahti
handle :: rezonant
freenode :: xfury
blog :: http://xfurious.blogspot.com/
site :: http://komodocorp.com/~wilahti