[Clam-devel] Re: OSC in CLAM

[Pau Arumí]

On dj, 2008-07-31 at 16:52 -0400, Han, Yushen wrote:
> Hi, Pau
> 
> Thanks for your commit 11704 and 11709. Here I have 3 problems related
> to your commit about the OSC plugin using liblo.
> 
> When I was trying to integrate OSC (using a simple Liblo) as the input
> to drive my plugin in realtime:
> (1) I could not open threecontrols.clamnetwork in my NetworkEditor due
> to "error creating a processing object of type 'LibloSource' which is
> not available.
> 
> "Not available processing" is an old problem haunted my NetworkEditor
> - it had problems in finding plugin processings.
> I tried to compile CLAM first, plugin second and NetworkEditor third
> yesterday but it did not help.
> I wonder how NetworkEditor looks for processings belong to the plugin.
> Why could it find many other processing? Can you explain a bit?

NE uses the RunTimeProcessingLibraryLoader to load CLAM plugins. Check
its code, and it's base classe code (in CLAM/src/Processing/Plugins). 
It basically tries to open all files in CLAM_PLUGIN_PATH and system and
local clam dirs.

Double check that you are installing the osc library, and it is either
installed into a system dir
(/usr/local/lib/clam, /opt/lib/clam, /usr/lib/clam), or you have defined
CLAM_PLUGIN_PATH to the install prefix.

Also, to check what is going on with the library loading, uncomment
lines 34 and 51 in  RunTimeLibraryLoader.cxx
It will say the dirs and files it tries to load:
//	std::cout << "[" << libraryType() << " Plugins] FullyLoading " <<
libraryPath << std::endl;

Try this and report back.


> 
> (2) To circumvent problem (1), I made a simple "myLibloNetwork.cxx" as attached.
> However it complained "No out port named 'osc to control 1'." in runtime.

Let's first concentrate on fixing the loading for NE...

> ------
> Last week I add some post-voice processing to deal with the transition
> between voices more gracefully.

I don't know how to emphasize more that in the GSoC program is about
code. We should be discussing and integrating patches very often.
So, let's do patches.

> Also, I merged my and Greg's plugin together -> realtimeSMSSynthesizer.
> I removed all header files included only by his plugin from the system fold.

Good, this is a hi-priority task. Patches? 
Also remember (see my last mail) to send a patch with a score file, so
that anyone (and I) can test the synthesizer.

> ( But I felt that we were dealing with instruments of different
> natures. Mine was more note-based while his is more continuous. The
> user would have to give verbose parameters from the command line for
> different sound.)

Yes it makes sense.

P