Re: [Traverso-devel] Sample OSC Implementation [patch included]

[Remon]

Hi,

> > * Since OSC doesn't operate in a 'context which is dependend on the mouse
> > position', but rather gives programmatic control of the application, the
> > question arises if a) existing infrastructure for dispacting events can
> > still be used. b) if there is need for a 'ProgramaticInterface' which
> > operates in a similar way as the current SongCanvas, but without the GUI.
>
> This would be some sort of internal API within the system?  I thought that
> this was the purpose of the Command class hierarchy.

Yes, sort of. With the Command classes we can do many things in one go: 1) 
redo 2) undo (including the history of course) 3) jog mouse board feature 
4) 'hold type' actions can have modifier key actions, e.g. [ G ] + mouse 
wheel

Depending of the type of actions it's the perfect choice to control the core, 
yes.
On the other hand, you need pointers to Core objects to create those Command 
objects for/with.

> > This PI retrieves pointers to core Objects after a Project load, and
> > connects to the important signals of the core.
> > Benefit is that the PI has it's own set of pointers to core Objects (like
> > Song, Project, Track etc) and doesn't need to query the core lib (which
> > could be unsafe when an event is being processed by Tsar !!).
>
> Ah, so are we dealing with multiple threads of execution here?  How does
> one safely access Core?

True. The current songcanvas provides a visual part for most of the core 
objects. Each visual part (ViewItem) has a pointer to it's corresponding core 
object, and stores the child viewitems in a list, so that the same object 
hierarchy exists but then with gui objects, each holding a pointer to it's 
core counterpart.
Due this, the core never has to be accessed to get data about new or existing 
objects, since the songcanvas and it's viewitems get updated by means of the 
FooAdded/FooRemoved(Foo*) signals.

Core items that are related to audio processing (Song, Track, AudioClip etc) 
are stored in a list, and this list is only modified by the audio processing 
thread. This garuantees that the audio processing thread never can access 
objects that are removed from within the GUI thread, and there is also no 
need for mutexes to guard those lists.
Since a couple of weeks the lists have been converted to a simple linked list, 
so it might not be as important as before, specifically when the list 
pointers are updated atomically. (but that remains a bit of a black art to 
me)

> > * What about moving it into either it's own subdir, or see it as an
> > extension to InputEngine, and thus add the SCO logic (at the least) to
> > the core lib (instead of common, which is no lib at all)
>
> Given that everything is at present statically linked, I confess that the
> intended partitioning of the system library-wise is somewhat escaping me.
> Could you lay out the Big Picture of what is intended to be grouped
> together?

Placing classes in a logical place, subdirs in this case, and to speed up 
compilation. Another aspect is re-use of internal libs, like creating a new 
type of GUI, reusing the audio-engine backend somewhere else, ability to load 
a CommandPlugin and it's Commands at runtime, etc.
However, since Traverso is the only application that makes use of those libs, 
I figured that linking statically makes life easier, also for people who want 
to compile from source.

> > * could you make a list of at least a minimal set of options you want to
> > implement ? Like loading a track, creating a clip is one, but
> > starting/stopping a song another etc.
> > Depending on that list, it might be valuable to research if e.g. the
> > InputEngine can be used for most of it.
>
> I'll start putting together a namespace schema.

Great!

> > * I try to depend 'only' to Qt if possible, so std::vector/list/etc isn't
> > used, unless you think it's better then those of Qt. Probably a matter of
> > habit, preference... Not that important.
>
> I was not aware that Qt re-exported the base STL -- is this something new
> in Qt4?  I have used those constructs before under Qt3 without portability
> problems on either Un*x or Win32 (haven't tried OS X, but I'd be Real
> Surprised if there were any problems).

You can use Qt's containers and stl, also mix them, it's just a matter of 
preference :)
Like push_back() is ???
append() or prepend() (the Qt way) seems more logical to me.

> > Well, these are just some thoughts, also inspired by your off-list email
> > (that you like to control the GUI, which is exactly what we don't do in
> > Traverso :) )
>
> Well yes, that was just a manner of speaking.  We do need to have *both*
> humans and OSC able to control the system at the same time though.  Your
> earlier remarks were sounding like you were assuming an either/or
> situation.

Ah, OK. 

Of course, if both are needed, then it's no problem to have them both at the 
same time.

Hope that this explanation makes things a bit clearer, why I designed it this 
way, and well, some things just 'grow naturally' and that could also be a 
wrong way :)
If you have opinions or questions, please share them !

Now bedtime, sleep well, have a nice day, etc

Remon