[PD] [gemhead]s vs. [separator]

João Pais jmmmpais at gmail.com
Sun Dec 6 16:28:42 CET 2015


My examples are very simple, so there won't be any problems with loops and  
no rendering orders have to be calculated.

Do I take from your comment that using [separator] does add more overhead  
than [gemhead]?

For my simple case, it seems that using both of them has the same result.  
But I would want to know what is exactly the difference.

Best,

Joao

> The [gemhead] also controls the order of execution of chains while  
> [separator] inherits that from the [gemhead].  One giant chain off a  
> single >[gemhead] with a bunch of [separator] will not give the same  
> results as a bunch of different [gemhead] with explicit order of  
> execution.  There is >some overhead with [separator] that can become  
> non-trivial if enough of them are used (like in a loop).  
> One thing that helps is to always give each [gemhead] a value for render  
> order.  This will avoid, or at least help understand, many problems with  
> >how rendering occurs.
>
> On Sat, Dec 5, 2015 at 9:15 AM, João Pais <jmmmpais at gmail.com> wrote:
>> Hello list,
>>
>> I don't work with GEM so regularly, so I had a question regarding  
>> independent processing chains.
>> I'm showing different [shpere]s, and wanted to do individual  
>> transformations on each, such as [color] and [translateXYZ]. Until now  
>> I used an >>individual [gemhead] for each [sphere], but I just learned  
>> that it can also be done using one common [gemhead] and [separator]s  
>> instead.
>>
>> I would like to learn, what are the pros and cons of each solution?  
>> Which solution is more efficient and for which reasons?
>>
>>
>> Plus: [color] and [colorRBG] seem to have the same function. Besides  
>> the extra inputs, is there any difference/advantage in one object  
>> instead >>of the other?
>>
>> Best,
>>
>> jmmmp
>>
>> _______________________________________________
>> Pd-list at lists.iem.at mailing list
>> UNSUBSCRIBE and account-management ->  
>> http://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20151206/b9fdf31b/attachment.html>


More information about the Pd-list mailing list