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

[Fred Gleason]

On Wednesday 05 December 2007 04:23 pm, Remon wrote:
> * For that reason I wouldn't use Interface.cpp to init and handle OSC, but
> rather see OSC as another way of an 'input event', but I could of course
> misunderstand the purpose of OSC.

No, I think that's a good design decision.  I put it into Interface merely 
because it was a convenient place to hang it without causing undue disruption 
to the existing codebase.  OSC can really be thought of as a 'peer' to the 
GUI (being in essence just another view of the core) and so should really not 
be messing with the internals of Interface.


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


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


> * 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?


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


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


> * qmake is compilation is becoming deprecated (at least that's true for >
> Traverso 0.42.0), we're using cmake now....

Oh goody -- a new build system to learn...  :)


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


> Short is relative .... :P

Yeah -- and time is money...  :)

Cheers!


|-------------------------------------------------------------------------|
| Frederick F. Gleason, Jr. |               Chief Developer               |
|                           |               Paravel Systems               |
|-------------------------------------------------------------------------|
| The fountain code has been tightened slightly so you can no longer dip  |
| objects into a fountain or drink from one while you are floating in     |
| mid-air due to levitation.                                              |
|        Teleporting to hell via a transportation trap will no longer     |
| occur if the character does not have fire resistance.                   |
|                           -- README file from the "NetHack" game        |
|-------------------------------------------------------------------------|