[Clam-devel] Re: OSC in CLAM

Pau Arumí parumi at iua.upf.edu
Mon Aug 4 01:59:17 PDT 2008


On dg, 2008-08-03 at 20:09 -0400, Han, Yushen wrote:
> Hi, Pau
> 
> Thanks for your instruction to uncomment the debugging information.
> 
> I think I loaded the library needed by OSC:
> [CLAM Plugins] FullyLoading
> /usr/local/lib/clam/libplugins_continuous_excitation_synth.dylib
> [CLAM Plugins] FullyLoading /usr/local/lib/clam/libplugins_osc_source.dylib
> [CLAM Plugins] FullyLoading /usr/local/lib/clam/libplugins_spacialization.dylib
> 
> But it still did not work ( full error messages are given below ).
> I think "osc to control 1" is the right port name but why it failed to
> recognize that?

The message below seems related to loading a network. But you don't
specify what network it is.

The first check is "do [plugin] Open Source Control" appears in the
Processing Tree? Are its LibloSource and LibloSink instantiable?

If this is ok, check the content of the .clamnetwork file to spot the
problem.

plugins/osc/threecontrols.clamnetworks should open (at least it does
here)


> 
> If I have more than one copy of the same .dylib file, it will give me
> warnings like " id xxx already registered".
> So I kept only one copy for each of my .dylib files in /usr/local/lib/clam.
> I removed all other copies in /usr/lib/clam and ~/.clam/plugin etc.
> Is that the right way to go?
> Why did it install multiple copies of the same library?

Yes avoid multiple plugins installed.
Plugins are installed in the clam_prefix dir passed to scons as option
(and saved --cached-- in the file options.cache).

P



> Best regards,
> Han, Yushen
> 
> 149-159-132-38:examples yushen$ ./myLibloNetworkExe
> [CLAM Plugins] Looking at path '/Users/yushen/.clam/plugins'
> [FAUST DEBUG] 	Using environment path: /Users/yushen/.clam/plugins
> [CLAM Plugins] Looking at path '/usr/local/lib/clam'
> [CLAM Plugins] FullyLoading
> /usr/local/lib/clam/libplugins_continuous_excitation_synth.dylib
> [CLAM Plugins] FullyLoading /usr/local/lib/clam/libplugins_osc_source.dylib
> [CLAM Plugins] FullyLoading /usr/local/lib/clam/libplugins_spacialization.dylib
> [FAUST DEBUG] 	Using environment path: /usr/local/lib/clam
> [FAUST DEBUG] 	load of RunTimeLibraryLoader
> ##########################################################
> ######################## WARNING #########################
> ##########################################################
> At file scons/libs/core/include/CLAM/Factory.hxx line 280
> WARNING. While adding a creator method in the factory, id 'LibloSink'
> was already registered.
> ##########################################################
> ######################## WARNING #########################
> ##########################################################
> At file scons/libs/core/include/CLAM/Factory.hxx line 280
> WARNING. While adding a creator method in the factory, id
> 'LibloSource' was already registered.
> Starting the server
> LibloSource::ConcreteConfigure: STARTING the server. port 8000
> ##########################################################
> ################### ASSERTION FAILED #####################
> ##########################################################
> At file scons/libs/core/src/OutPortRegistry.cxx line 44
> No out port named 'osc to control 1'.
> Try with:
>  Unable to adquire symbols names for the backtrace
> 
> 
> On Fri, Aug 1, 2008 at 3:53 AM, Pau Arumí <parumi at iua.upf.edu> wrote:
> > 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
> >
> >
> >





More information about the clam-devel mailing list