Hi Jonathan,
Thank you for your reply. In the mean time I also found that the same
discussion has come up before, so sorry for starting it yet again. I
read that the documentation about jack overhead and mistakingly thought
that inlining as much as possible would be the best idea. I now
understand why you are opposed to LV2. Also the description that OSC is
better than MIDI led me to believe that OSC would be the way to go, but
for non-sequencer that is of course not true.
I will try to explain the problem with the Event Editor of non-sequencer
better. When I start the Event Editor I can insert e.g. a CC message.
Then I can change the position, CC-number and value. When I save it
turns out that the position is not saved but is always 0. In other
words, I cannot insert a CC number at a specific position. I don't think
this behaviour is what a regular user will expect, especially since the
position can be changed.
In case you are wondering why I work this way, I am working with an
artist and have programmed an Arduino to do visual effects. The visual
effects are then synced with music by sending MIDI to the Arduino. It
would be stupid to program the same set of effect changes twice (e.g.
have the same effect changes in all choruses) and non-sequencer is
eminently suited for this. I do not need to copy stuff but just add the
effect tracks I need and order them order them in non-sequencer. Not
being able to change the position of an inserted messages makes this not
a nice task since I have to do it somewhere else and import that MIDI
file (an re-import after something changes!).
My remark about FLTK also is about non-sequencer. Click Sequence and
then Detach. Now start playing and in the detached window mute a track.
The status of the track is not updated in the original window. This is
because there is too little separation between Model and View in FLTK.
Normallly you would implement track status in the model. When someone
does an action it will update the track status in the model (called the
Controller part). The Views that show the track status are listeners to
the model, will get notified that the status has changed and update
their view accordingly. This will work for any number of views on the
same data item. FLTK does not have a listener interface so you have to
implement it yourself. And no, this will not make your program noticably
slower when implemented correctly.
Kind regards, Ruud
On 03/09/2019 00:13, J. Liles wrote:
Not Richard, but responding anyway.
On Mon, Sep 2, 2019 at 2:39 PM Ruud Mulder <[email protected]
<mailto:[email protected]>> wrote:
E.g. why is there no OSC in non-sequencer,
Well, for one thing it's a completely open question what OSC would
even do in a sequencer. OSC is way more flexible and open-ended than
MIDI. Anyway, It would be some kind of horrible hack to try any store
the OSC events in a MIDI file (which is what non-sequencer reads and
writes). If you have some coherent and sensible ideas for how this
could work, the world may be listening. Might as well ask why there's
no Tetris game built in.
there is someone who added LV2 plugins but it is not merged into
the main development (why?).
LV2 support was not missing in the first place due to lack of
development resources. It was intentionally omitted because LV2 does
not align with the goals of the project. In short, LV2 is a
comparatively heavy-weight and heavy-handed dependency, but doesn't
offer much, if anything, over LADSPA (unless you count hype as a pro).
I see LV2 in the same general light as systemd, if that clears matters
up any.
Also there are small but annoying 'features'. Open up a separate
window for the tracks and mute a track. In the main window the
track status is not updated. It is the way FLTK seems to work.
There is too little separation between the view and the model.
This has nothing to do with speed. The listener model is well
known and updates all views fast enough and this can be added to FLTK.
This description is not sufficient for me to understand the nature of
the complaint. I can't even tell which application you're referring
to. However, I can tell you that whatever it is you're describing is
very unlikely to be due to a limitation of FLTK/NTK.
The same issue applies to your CC event editor problem. The
description of your workflow, i.e. what you're trying to do and how
non-sequencer is preventing you from doing that is not sufficient for
me (or anyone else, probably) to respond to it intelligently with
anything other than a quiz. The event editor was never designed to be
a primary input method, I'm sure there's room for improvement and it's
likely that a minor tweak or better instructions would solve your
problem. I'm just not sure what the problem is.
