[Clam-devel] Re: OSC in CLAM

[Pau Arumí]

Hi Yushen,
I've done a little housekeeping in the plugins/osc

commit 11704

 * deprecated (moved to deprecated/) osc-example.clamnetwork
 * fixed threecontrols.clamnetwork (added ServerPort attr)

commit 11709
 * added new processing LibloSink


On dj, 2008-07-24 at 17:01 -0400, Han, Yushen wrote:
> Hi, Pau and Greg
> 
> I was able to compile the osc plugin after I installed the liblo-0.25.

> However, I still could not open osc-example.clamnetwork in /clam/plugin/osc
> because "OSCSourceProcessing" is missing from NE.


osc-example.clamnetwork was using the processing OSCSourceProcessing,
based on oscpack lib, so it's discontinued. We changed from oscpack to
liblo because it is well distributed, while oscpack is not in Debian
repos (because of license issues)

> I have 2 questions:
> 
> (1) Should this osc plugin work with NE after compiling? Do I miss anything?

Now the existing clamnetwork (which is a LibloSource -> ControlPrinters)
should work

> (2) How can I test the osc with what I already have?

LibloSource|Sink is just a starting point for a more serious OSC
processing development. Right now it is limited to 3 float parameters
which are sent to out ports. At least the number of ports should be
dynamic.

The more straightforward way to integrate with a synth could be using
controls. For that you need to model a note using float controls (or
ints and bools sent as floats).
Of course, for that you need the synth working in streaming mode (that
is, in NetworkEditor) 


> In testOscClient, I find out some information about testing osc with a
> mouse under Max.
> I am downloading Max5 now. Is that the right way to go?

Not really. Max is not open-source nor cross-platform. Of course, making
a synth OSC enabled (or MIDI enabled for the matter) allows using Max,
and that's great. But if you have to pick a (first) tool for controlling
the synth, choose something open-source (PureData, for example) allowing
a broader adoption (and testing from CLAM devels).

However, for normal developing with OSC I would neither use PureData
(nor Max). I'd just send controlled OSC events using some trivial python
script. You have an example here:
plugins/osc/oscpython/sendControlsOSC.py

To conclude, let me say once again that the top priorities of the GSoC
project now is having code integrated. Just do simple non-breaking
changes and send the patches. The first thing to address is having score
files commited and clear instructions on how to play the synth (only
using files inside the repos). Second, merging the two synths dirs
(since most of its code is repeated). And third, addressing the
streaming (or NE) version. 

Regards,
Pau