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

[Han, Yushen]

Hi, Natanael

Thanks for the documents.
I agree that there is no need to change the structure of the libloSource.
The point that I wanted to make is that we need to get the access to
the control value with or without forming a network.

Now all the outControls (outControlArray) in both libloSource and
MultipleLibloSource
"OutControlArray _outControls;" is defined as private.
This is perfectly fine if we want to compose a network in which we can
easily link any other processings with inControl.

However, I don't know how to get the control value from the source
without making a network.
(I suppose that we should link inControls to _outControls and get the
control value by GetLastValue().)

http://iua-share.upf.edu/svn/clam/trunk/CLAM/examples/ControlArrayExamples/MyProcessingWithSimpleControls.hxx
is an example of publicizing the control.

Attached is a patch that works for me. Maybe you want to change it as well.

Best regards,
Han, Yushen

On Tue, Aug 19, 2008 at 12:28 AM, Natanael Olaiz <nolaiz at gmail.com> wrote:
> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>
>>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: PublicOutControls.patch
Type: application/octet-stream
Size: 977 bytes
Desc: not available
URL: <http://lists.clam-project.org/pipermail/clam-devel-clam-project.org/attachments/20080821/9d13c651/attachment-0004.obj>