Re: [boost] Flow-based programming library for Boost?

Subject: Re: [boost] Flow-based programming library for Boost?
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2013-01-04 06:24:15

Le 04/01/13 11:36, Marcus Tomlinson a écrit :
> On 04 Jan 2013, at 11:46 AM, "Vicente J. Botet Escriba" <vicente.botet_at_[hidden]> wrote:
>
>> Le 04/01/13 08:51, Marcus Tomlinson a écrit :
>>>>> * You use a bus of input/output untyped signals. Why the signals are not
>>>>> typed?
>>> 1. Flexibility - inputs and outputs can dynamically accept changing signal types. E.g. Varying sample size in an audio stream.
>> I don't know why this couldn't be modeled with a vector signal containing the samples. Maybe you have other examples needing untyped iunterfaces.
> Sorry, audio jargon. Sample size - the size of each sample. So changing a vector<char> to a vector<int> for example. The sample type needs to change hence the vector variable needs to change.
Could you show a simple example that makes use of this kind of changes?
BTW, what happens when you connect a char and you try to get/set an int 
or a complex? Do you get an exception?
>>> 2. Less coding, more expandability - the component designer need not specify the types required at each input / output when configuring IO, only how many. Consider the situation where you would like to update a component to accept int instead of bool for one of its inputs. This would (in your implementation) require you to edit multiple sections of code. With DSPatch, you need only edit / add to the process method.
>> Well, my example is just a draft that can be polished. In particular the library could provide a macro that generates all this stuff from a free function.
>>
>> bool And(bool a, bool b) { return a && b);
>>
>> DSP_GENERATE_COMPONENT(And, DspAnd);
> This is better but still, the component is rather limited. It can only deal with 2 Boolean inputs and output a single Boolean. There is hardly room here to expand on IO count and types if needed in the future (perhaps at some point I'd like DspAnd to return "1" when x number of input integers are "1"). Again, I have to stress that these aspects of flexibility are very important to the purpose DSPatch serves. This makes me wonder though, perhaps I could use macros to simplify / enhance some aspects of DSPatch.
Could you show a simple example that show how the impact of this kind of 
changes ?
>
>>> This looks like the kind of code you'd find in other dataflow libraries. However, this is exactly why I designed DSPatch, and why I designed it the way I did. In my opinion, the code is convoluted (doesn't read well). But alas, I fear that most people actually prefer this kind of syntax over mine.
>> Syntax preference goes after covering all the needed functionalities. So I think that you will need to describe the needs you try to cover so that people like me don't request why you are doing things like you do ;-)
> If you have a quick look over the feature list on the main page of the DSPatch documentation site (adaptaudio.com/DSPatch) you'll see what this library achieves by doing things the way it does.
Indeed I did. But I don't found nothing showing the dynamic aspects you 
are talking of. It seems that more tutorials/examples are needed.

Best,
Vicente