thank you!
i figured that problem out too, but somehow i didnt realise this as a
cpuload problem. but now as you mentioned, it becomes clear!!!
have to try this later!...
greets chris
Am 04.08.2010 14:55, schrieb cyrille henry:
ok,
i don't have all of the OSC stuff, so i can't fully test your patch.
could you provide the minimal version that trigger the problem and
send it to the list (not only to me)
(the list would prefer a zip file)
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
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
_______________________________________________
[email protected] mailing list
UNSUBSCRIBE and account-management ->
http://lists.puredata.info/listinfo/pd-list
