Javier Serrano Polo wrote:
>> The changes consist of two main parts.
>> 1. I have added code to 'songEditor::processNextBuffer' to map the
>> current play position to 'piano_roll' units. This makes the play
>> position indicator of the piano roll move when the song or BB is being
> Got the idea. It needs some polish. But after using the play_song mode,
> I get a segfault when loading a pattern.
Yes, I've already fixed this problem - I had made a last minute change
to how the time line position was updated, and got bitten by the
classical 'operator= not inherited' nuisance in C++...
>> 2. I had to make additional changes to 'pianoRoll::recordNote' to get
>> the start position of the recorded note, in face of looping and multiple
>> BB items. This duplicates some of the logic introduced in 1 - but since
>> the recording gets the note only at note end this seems hard to avoid.
>> I have not made any changes in the user interface. To use the new
>> recording functionallity, press play in the song or BB editor, and then
>> turn on recording by pressing record (in the piano roll). This was
>> implemented for testing, a better interface could definately be introduced.
> I'm quite annoyed with that feature: recording while looping? Is that
> useful? I expected the normal recording behaviour.
My goal was to allow overdub recording whenever playing. This means that
notes should be added at the current play position. Whether this is
useful is a matter of personal opinion I guess. What I wanted to do was
to allow the work-flow you can use with seq24, where you have some of
your patterns looping in the background, and then record in a new pattern.
All of this was actually achieved by change 1, but since LMMS don't
report note on/ note off for recording, but instead only note off plus
length, I had to do the changes in 2, to avoid getting notes recorded
_before_ the start of the pattern.
Question: What do you mean with 'normal recording behaviour'?
> I like the upper keys extension. About the lower ones, there shouldn't
> be any repeated key. Pressing the same note with two different keys
> (yes, I do that) ends up in no sound.
> We could shift the lower keyboard to the right and gain seven additional
> notes. But I'd like to hear some feedback from (non-MIDI) keyboard users
I see your point. For me this is not a problem, since I mostly play only
with one hand. To me the overlapping notes means I don't have to switch
"manual" in the middle of a movement. Perhaps the duplicated keys should
be handled as if they physically were the same key? That is if one was
pressed followed by the other, and then the first released, the tone
would still be active, and not stop until the second key was released.
(Side note: the overlapping notes are more or less standard with tracker
I could resend the patch with my fix to the first problem, but I have
not been able to compile with the latest head, since some problem
introduced by the QT4 compatibility. I guess it is better to come to
some kind of agreement to how the overdub recording is supposed to work