Hi Roman,
you're absolutely right, in fact that's the way I'm doing. but I suppose that having the possibility to directly set the object would allow to have better performances.
Imagine a situation where you have 10 [ctlin] objects in a patch and then you implement the kind of filter we're talking about (a couple of [spigot] and [==] in my case). in this scenario, every time a CC message is sent to the patch, all these objects are exercised ([ctlin] + 2 [spigot] + 2 [==], all of them * 10). this wouldn't happen if [ctlin] had 2 inlets to set the arguments on the fly. all the processes would happen under the hood, within the 10 [ctlin] objects, without involving other objects.
cheers,
Mario
2018-03-31 12:04 GMT-03:00 mario buoninfante mario.buoninfante@gmail.com:
Hi Roman,
you're absolutely right, in fact that's the way I'm doing. but I suppose that having the possibility to directly set the object would allow to have better performances.
sure +1
On 03/31/2018 05:10 PM, Alexandre Torres Porres wrote:
2018-03-31 12:04 GMT-03:00 mario buoninfante mario.buoninfante@gmail.com:
Hi Roman,
you're absolutely right, in fact that's the way I'm doing. but I suppose that having the possibility to directly set the object would allow to have better performances.
sure +1
saying "better performance" is somewhat a no-brainer, but do you have any estimate on *how much* better that performance would be?
e.g. Pd can easily process enough midi-messages to make pianos talk¹ on a rpi2-like arm processor. would the extra CPU power you get by the performance boost of a ctlin inlet allow you to make money with hashcoins?
or to quote knuth: "premature optimization is the root..."
fmsdr IOhannes
PS: there probably isn't any good reason to not have additional inlets for [ctlin]. but performance is in an entirely different realm.
-
Alexandre Torres Porres -
IOhannes m zmölnig -
mario buoninfante