It was possible that the resize operation would move the completely
wrong note off if resizing from the right. The work around was to
have the search for note off begin right after the note off instead
of at the same position. The effect is that it cannot find note on
off pairs that effectively give the note duration zero.
Eighth note quantization with triplet button pressed now
quantizes new notes so that the three notes fill a quarter,
and so on. Before this relationship was wrong. Fixed now.
And removed the ad-hoc arrow graphics. However their remnant
code is still largely intact since the state flags for those
arrow graphics was used for the cursor changes.
When volume, pan, or program change on a track, the widgets in
the track settings module update to show the change. They also
display the current value in decimal when you are editing them.
This makes the program widget on the second panel actually useful.
The bank does not update and needs more work before it can be
fully functional (MSB/LSB).
The pan widget now has a different display.
Pressing pause, stop, and editing patterns while transport is running
causes playing notes to stop. Instead of using 'all notes off' controller
change messages, the sequencer keeps track of playing notes and does
a fast search to see which ones to cancel. This reduces midi bus traffic
considerably.
There is a potential race condition because both the audio thread (while
sequencer is playing) and the GUI (when changes are made) manipulate the
bit field used to track notes that are on. A possible error is when the
user presses a control or edits a pattern just as a note should be ending.
By the powers of multithreading, two note offs may be generated when there
should only be one. I am considering this rare and harmless enough at this
time to ignore it. Doing it correctly would require a better serialized,
lock-free command queue, and would solve a few other race conditions. Maybe
some other time.
Now the audio thread schedules recorded events after it has
played the existing events in that time period. Before it
may have been that recording would happen before playback,
resulting in two copies of that event being output: one from
forwarding and one from playback.
Box selecting piano roll notes failed to properly allow
event editor to modify only those notes.
Right click de-selecting all notes in piano roll failed to
restore modify-all behavior to event editor.
Box selecting in event editor selected notes even if not
viewing note on events.
All bugs fixed.
An undue latency on looping was removed as well as incorrect
implementation of jack transport. Now play, stop, and reposition
will send jack transport messages, but epichord will not respond
to such messages itself. I have an idea of how this could be
correctly done, but it would take some work.
Epichord still works, but likely does not fully function as a jack
transport client. Need to find details about how this is supposed
to work.
The only bug is that jack_transport_stop() does not seem to let
other clients (including epichord itself) know to stop. Epichord
has a temporary work around so it can stop itself.
This allows for exact triplets in some basic cases. Also TICKS_PER_BEAT
can now be changed to any reasonable value. Values less than 128 will
probably fry epichord's brain, and values greater than 65535 will cause
the midi file saver to fail.
But really the q_tick variable needs to be changed to reflect
the triplet quantization. Actually that will not work if the
ticks cannot be divided by three. Once I change TICKS_PER_BEAT
this will not be a problem of eigth note or sixteenth note
mode, but not necessarily for others. Must investigate further.
Replaced obvious 128s with TICKS_PER_BEAT. Will now begin
testing to see if 128 can be changed to 288 or more for the
purposes of allowing correct triplets.
Inserting triplets works better now. Probably more triplet related
bugs in the pattern editor.
This was a much wanted feature. Toggle the triplet button in
the pattern editor and notes will snap to time positions which
are as close to thirds of grid vertical rules as possible. The
quantization resolution settings affect what exactly is being
divided in three.
At this time there is a bug. A beat is divided into 128 ticks which
is not divisible by three. This is semi hard coded and needs to be
made configurable at compile time. A default value of 288 would make
more sense.
The selected track's port is now used as the output port
for the input pass-through, aka record pass-through. The
bug was that changing tracks didnt affect which port was
used.
These bugs have been caused by logical errors
in the manipulation of the pattern data (linked
list). In particular when new and old events
accidentally refer to themselves or no-longer
-existing events. More bugs surely remain.
Events are now sorted in time before they are
dispatched. This solves rather large timing errors
in which the kludge was to send all out of order
events and following events on the last index of
the frame buffer.
An arithmetic error was causing ticks and target
frames for events to be off by 1, sometimes. This
mostly caused the above kludge to trigger, but sometimes
resulted in a negative target frame (zero minus one).
That would cause a segfault.
Fixed.
dispatch is no longer a function pointer passed to the
play function in the sequencer. It is just a function
defined in the backend implementation file.
Nedko Arnaudov
EvanR
evan