[Clam-devel] Re: Multi server-paths LibloSource

Natanael Olaiz nolaiz at gmail.com
Mon Aug 18 21:28:00 PDT 2008


Reading further the links that I sent, I see that you can send the 
messages using the server:

        int lo_send_from(...): Send a OSC formatted message to the
    address specified, from the same socket as the specificied server.

That is what you used your modified MultiLibloSource?


El 08/19/2008 01:17 AM, Natanael Olaiz escribió:
> El 08/18/2008 05:41 AM, Han, Yushen escribió:
>> Hi, Natanael and Pau
>>
>>   
> Hi Yushen,
>
>> Here is a simple patch for MultiLibloSource.hxx
>> I modified its GetConfig() to return the correct type of cfg.
>>
>> -       const CLAM::ProcessingConfig & GetConfig() const
>> +       const CLAM::MultiLibloSourceConfig & GetConfig() const
>>
>>   
> I don't think ProcessingConfig is an incorrect return type. Is the 
> abstract class, returned by the other processings.
>
>> Also, in my own working copy I integrated InControl and OutControl
>> into the MultiLibloSource
>> For my synthesizer, the point is to use GetLastValue() from InControl
>> to read what has been sent to the port.
>> (The OutControlArray is given in the callback function and I paired
>> InControl and OutControl programmatically.)
>>   
> Sorry, but I don't understand what you means. Please send a patch, 
> and/or explain a little more. ;-)
>
> Anyway, I can't figure any sense to merge InControls and OutControls 
> in MultiLibloSource. MultiLibloSource manages the servers needed to 
> receive OSC. The sender (LibloSink) is just a client, which not needs 
> any management (http://liblo.sourceforge.net/docs/group__liblo.html ; 
> http://liblo.sourceforge.net/examples/ )
>
>> There is no need for a LibloSink then ( I am not sure why the original
>> design has Source and Sink separately for OSC).
>> What's your opinion, Natanael and Pau? Thanks!
>>   
> What I wrote above. Why you don't want to have two processings? I 
> don't see a problem in the desing of using one sender and one receiver 
> separately.
>
> But maybe if you explain a little more your problem I would understand 
> what you wanted to means..
>
>
> Cheers,
> Natanael.
>> Best regards,
>> Han, Yushen
>>
>> On Sun, Aug 17, 2008 at 3:26 PM, Natanael Olaiz <nolaiz at gmail.com> 
>> wrote:
>>  
>>> El 08/17/2008 12:52 PM, Han, Yushen escribió:
>>>    
>>>> Hi, Natanael
>>>>
>>>> Good job in MultiLibloSource!
>>>>
>>>> Now my plugin that needs to read 2 or 3 arguments from a OSC source is
>>>> working in NE.
>>>>
>>>>       
>>> I'm glad to know that. It seems to be working good, and is very 
>>> useful for
>>> the Blender integration too.
>>>
>>> Anyway, don't look at the semantics on code (for now...) ;-)
>>>
>>>    
>>>> Thanks!
>>>>
>>>>       
>>> Thank you for the feedback.
>>>
>>>
>>> Cheers,
>>> Natanael.
>>>    
>>>> Best regards,
>>>> Han, Yushen
>>>>
>>>> On Sat, Aug 16, 2008 at 3:28 AM, Natanael Olaiz <nolaiz at gmail.com> 
>>>> wrote:
>>>>
>>>>      
>>>>> El 08/15/2008 03:12 PM, Natanael Olaiz escribió:
>>>>>
>>>>>        
>>>>>> Commited on r11988 as MultiLibloSource:
>>>>>>
>>>>>> * MultiLibloSource: a copy of LibloSource with multiserver 
>>>>>> (ports) and
>>>>>> multipaths support.
>>>>>>
>>>>>> Still needs semantics renames and doesn't check for duplicated 
>>>>>> paths....
>>>>>>
>>>>>> El 08/15/2008 07:02 AM, Natanael Olaiz escribió:
>>>>>>
>>>>>>          
>>>>>>> I send a patch because I still need to refactor, review clean up 
>>>>>>> and
>>>>>>> check the semantics (to do after sleep...).
>>>>>>> But it works! With this I will not need specifics osc receivers for
>>>>>>> Blender!! :-)
>>>>>>>
>>>>>>> Using a static map to manage the needed servers by ports, and
>>>>>>> processings
>>>>>>> instances (the first configured processing on that port create the
>>>>>>> server,
>>>>>>> the last one remove it)
>>>>>>>
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Natanael.
>>>>>>>
>>>>>>>             
>>>>> At r11992 I think that finally MultiLibloSource is stable! :-)
>>>>> If someone else try it, please tell me how it works.
>>>>>
>>>>>
>>>>> Cheers,
>>>>> Natanael.
>>>>>
>>>>> _______________________________________________
>>>>> Clam-devel mailing list
>>>>> Clam-devel at llistes.projectes.lafarga.org
>>>>> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel 
>>>>>
>>>>>
>>>>>
>>>>>         
>>>>       
>>>     
>
>





More information about the clam-devel mailing list