Re[2]: [Octal-dev] porting thoughts

[ccastiglione]

____________________Reply Separator____________________
Subject:    Re: [Octal-dev] porting thoughts
Author: "Bullwinkle J. Moose" <address@hidden>
Date:       6/16/00 3:16 AM

>Actualy, what was going threw my mind was something similar to what VIM 
>has done since about v5.4.  At compile time you can specify weather or not 
>to use an Athena interface, a Motif/Lestif interface, or a GTK interface.

Sad to say that although I've been hacking on Unix boxes for school and work for
several years now, I'm still not Linux-savvy.  I've got a machine in my studio
that's destined to become a Linux dual-boot as soon as I have an electrostatic
wriststrap and a few hours of spare time.  Should happen sometime before the Sun
collapses :)  So...what's VIM?  Never heard of it.

>On the other hand, the idea of haveing two fully seperate binary files 
>running, and communicating with some sort Client / Server mesage passing 
>mechanism present a great deal of posibility.  (would CORBA be at all 
>aplicable for this?)

Possibly, though doesn't CORBA require all senders / recipients to be objects? 
I was thinking of something more modest, like a mailbox mechanism to handle
IPC's, but sends messages as text strings (easier to debug and also not reliant
on a 3rd party platform -- not that CORBA isn't widely supported).  But then
that's just what I'm used to seeing; I'm sure there are other ways.

>It sounds as if it would posible to arange it so that the controling 
>signals are then comming from almost anywhere, like perhapse an external 
>MIDI controler?  Or another application, a sequencer maybe?

Em, yes, that's entirely possible assuming that the Octal "listener" is written
such that it can respond to requests from multiple sources.  Not a bad idea. 
Tricky but possible.

>Is it worth it?  Is all the flexability and power worth the slightly more
>complex development track? i would think it is, but that it just my >opinion...

Righty-right, I agree.  But I also see that it's damn hard to continue work on
the back end without having a useable GUI.  If nothing else, it makes debugging
new work -- like the wavetable and other stuff that appears still to be in
development -- a lot harder if you can't run the thing in roughly the same way
you'd expect the users to run it.

On the other hand, deciding that this is an worthwhile goal for the future still
has an impact on certain aspects of design.  Like, I noticed that the (x,y)
parameters of each machine instance are stored as part of the machine's state as
designed now, but if the UI is really separate then that info is irrelevant to
the audio engine and shouldn't be stored there.  (Imagine having to pass
messages between the UI and server everytime the user dragged a machine around
-- ick!)

Chris