Found the performance thief! Removed a debugging [print]. Now it performs as wanted!
Thank you cyrille!
Am 04.08.2010 um 15:07 schrieb cyrille henry ch@chnry.net:
anyway, i think i found a problem.
in your MIDIctlin abstraction : whatever midi message received, this abstraction did output the CC
value if port and canal is the good one, but it did output 0
otherwise. so a single midi message generate 81 send for each
sendOSCChannelstrip. and you have 8 of them.this 648 UDP message are send to both localhost and over the network
(192.168.0.30) this still did not explain the 20 min wait, but if you use this
version of MIDIctlin, it will greatly reduce problem.c
Le 04/08/2010 14:44, Christoph Kuhr a écrit :
well,
i have a main patch (MOD_8) including all the numberboxes and only recieving via udp. works fine. it also calls an abstraction (sendOSCMod_8), which manages all the sending: 8 channelstrip (sendOSCChannelstrip) abstractions are called with 33 FILTERED(MIDIctlin) [ctlin]. calling the sending abstraction alone without the main patch causes
the same problem, and there are no numberboxes in it.attached the patches
bye chris
Am 04.08.2010 14:26, schrieb cyrille henry:
hello, what you describe should use a negligible % of CPU. i think there is a problem somewhere. something like a loop with
send and receive by example.send your patch to the list so we can have a look.
c
Le 04/08/2010 14:06, Christoph Kuhr a écrit :
Hi there,
im working on a digital mixing desk, any channel is build of 33 MIDI CCs one CPU has to manage 8
channels for using ctlin with dynamic arguments, i put it in an
abstraction, did two multiplications and two compersisons. when i change a CC value the pd-gui is getting REALLY busy,
computing about 20 minutes for that one value.do you have any ideas, on how to do that more CPU saving?
greets chris
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
<MIDIctlin.pd>