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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> >>>>> 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 >>>>>> [email protected] >>>>>> >>>>>> https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >> >> > >
PublicOutControls.patch
Description: Binary data
_______________________________________________ Clam-devel mailing list [email protected] https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel
