Hello, everyone!

View: New views
5 Messages — Rating Filter:   Alert me  

Hello, everyone!

by William Lahti :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
LMMS-devel mailing list
LMMS-devel@...
https://lists.sourceforge.net/lists/listinfo/lmms-devel

Re: Hello, everyone!

by Bugzilla from eagles051387@gmail.com :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

not much of a contribution to the whole post here. but whats in the ubuntu repos is an older version version 4.2 the latest version though is version 4.5 which you can get from lmms.sf.net either as a package or from source

On Sun, Oct 4, 2009 at 1:57 AM, William Lahti <xfurious@...> wrote:
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

------------------------------------------------------------------------------
Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
http://p.sf.net/sfu/devconf
_______________________________________________
LMMS-devel mailing list
LMMS-devel@...
https://lists.sourceforge.net/lists/listinfo/lmms-devel




--
Jonathan Aquilina

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
LMMS-devel mailing list
LMMS-devel@...
https://lists.sourceforge.net/lists/listinfo/lmms-devel

Re: Hello, everyone!

by William Lahti :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Sun, Oct 4, 2009 at 4:51 AM, Jonathan Aquilina <eagles051387@...> wrote:
not much of a contribution to the whole post here. but whats in the ubuntu repos is an older version version 4.2 the latest version though is version 4.5 which you can get from lmms.sf.net either as a package or from source

Hello, Jonathan, yes I'm aware of the oldness of the Ubuntu version. I am programming against the latest git version :-).

--
rezonant

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

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
LMMS-devel mailing list
LMMS-devel@...
https://lists.sourceforge.net/lists/listinfo/lmms-devel

Re: Hello, everyone!

by Paul Giblock-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

> 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.
>

Toby and I will have to review it, it sounds like some of these
features are indepth.

> 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).

This makes sense conceptually as long as the UI isn't too complex, also:

> 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).

As long as the user can still use the MidiPort's channel to specify
the "default". For when per-note-channels is not desired.

> 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.

Yeah, it was odd to me at first too,  AFAIK, the note is sent both to
the MIDI and to the LMMS-Instrument when MIDI-Out is set.
Having support for both _could_ be handy perhaps if you are in a
situations where your hardware synth is unavailable. But, I don't use
external synths so I wouldn't know.

> 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.

Yes, the FLP import is totally reverse engineered I believe.  However,
there are definitely cases in the code that are exposed but just not
handled.

> 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.

Don't bother with this.  I already have it planned in our Song-editor
rewrite.  Every Beat-line will have an explicit time-signature and
length associated with it.

> 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.

Not familiar with this one.  What version of Qt are you using?

> 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.

This is a huge undertaking actually.  And it is currently being
handled by my new song-editor code as well.  The song now has a
metric-map associated with it. This stores Meter and Tempo changes.
This way, song editor can be displayed in linear-time, and timesig and
tempo changes can be displayed with the TimeLine-widget.

> 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.

Yes. I noticed this as well.  You have to do "import" first, then
"new" which will close the window.  This is certainly a bug.

> 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

I'm excited about new developers ;).  I have a few documents.  I'll
try to move them to the Wiki. In the meantime, I recommend hanging out
in our IRC channel.

=Paul

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
LMMS-devel mailing list
LMMS-devel@...
https://lists.sourceforge.net/lists/listinfo/lmms-devel

Re: Hello, everyone!

by William Lahti :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

On Sun, Oct 4, 2009 at 10:57 AM, Paul Giblock <drfaygo@...> wrote:
> 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.
>

Toby and I will have to review it, it sounds like some of these
features are indepth.

Absolutely, I think you'll find the changes pretty elementary. Like I said, a lot of the work was already done for plugins that did their work with MIDI instead of playNote, and for the others it was as simple as adding one field (to at least make the capability available). I don't think I had to change VeSTige at all.

> 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).

This makes sense conceptually as long as the UI isn't too complex,

Yes, as it is so far in my modifications the toolbar just has one more button. There are more concerns though, particularly how to handle general editing of multi-input notes. I've changed the piano roll to display notes in the various colors, but changing the color of a the selected notes needs another action somewhere. Another button wouldn't be good imho, as the toolbar already requires the piano roll to be quite long (at least half of my 1280x800). I think some of the toolbars could be menuized, but I think that's a separate patch. Perhaps I should just assign a shortcut key for now, and provide the capability in a method on the piano roll widget so it can be called by a menu action later.

also:

> 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).

As long as the user can still use the MidiPort's channel to specify
the "default". For when per-note-channels is not desired.

By "default" do you mean normalizing it so all note events have the same channel, or being able to set the channel for the green (default) notes. If we want the former I would suppose that normalizing would occur for the Midi Out and not the VST? Right now it normalizes for both but that was for simplicity's sake rather than correctness.

> 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.

Yeah, it was odd to me at first too,  AFAIK, the note is sent both to
the MIDI and to the LMMS-Instrument when MIDI-Out is set.
Having support for both _could_ be handy perhaps if you are in a
situations where your hardware synth is unavailable. But, I don't use
external synths so I wouldn't know.

Ahh. But that would mean that the instrument plugin played too, unless you muted it, which I hope would prevent the plugin from processing. And from what I see, the way to do that is to mute the track, which would mute the midi out right?

Layering and chaining could be very useful actually. FL has layers, but it's a pretty weak concept which doesn't fit in nicely with the rest of the workflow. One issue I see is that entering piano rolls for one instrument which chains into others would be slightly confusing without some gui cues. Is this actually possible with the midi setup that lmms uses internally for instruments?

> 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.

Yes, the FLP import is totally reverse engineered I believe.  However,
there are definitely cases in the code that are exposed but just not
handled.

Right, we'll see.

> 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.

Don't bother with this.  I already have it planned in our Song-editor
rewrite.  Every Beat-line will have an explicit time-signature and
length associated with it.

Excellent. Having a time signature for a beat would be very useful but I think then there would have to be a way of dealing with beats/rolls with different time signatures being played together. I see that if they were all independent of each other (ie, not changing the time signature value of the song itself like one could do in FL) it would work but it would add a gotcha when writing songs. I would suggest a gui cue (which LMMS is particularly nice at, faded notes are coool).

> 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.

Not familiar with this one.  What version of Qt are you using?

Happens on LMMS 4.3 and git (as of a few days ago) with Qt 4.5.0 from Ubuntu 9.04 (GCC 4.3.3). The problem is intermittent. If it happens you can maximize any inner window and then restore it and it works again. Likewise I have noticed using minimize, resize, or other window operations seems to trigger it. These are anecdotal (if in the first person), as I wasn't taking notes.

> 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.

This is a huge undertaking actually.  And it is currently being
handled by my new song-editor code as well.  The song now has a
metric-map associated with it. This stores Meter and Tempo changes.
This way, song editor can be displayed in linear-time, and timesig and
tempo changes can be displayed with the TimeLine-widget.

Oooh, nice. I think I see what your getting at, that should make time-based dynamics much easier.

> 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

I'm excited about new developers ;).  I have a few documents.  I'll
try to move them to the Wiki. In the meantime, I recommend hanging out
in our IRC channel.

Thanks! I've been lurking in the channel for a bit, then rambled a long chunk of text in the IRC hoping to find a non-busy dev to talk to before bringing it to the list.

--
rezonant

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

------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
LMMS-devel mailing list
LMMS-devel@...
https://lists.sourceforge.net/lists/listinfo/lmms-devel