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>