Thanks for the report. What is the exact expected behavior and what is inside the pd~ abstraction?
BTW, I think the problem with the other issue is that ii is a synonym for init and I think I had this problem before where an object needs to be instantiated before its synonym is accepted. It may have been fixed upstream since the fork in which case I missed it.
-----Original Message----- From: pd-list-bounces@iem.at [mailto:pd-list-bounces@iem.at] On Behalf Of puredata@11h11.com Sent: Tuesday, April 01, 2014 5:19 AM To: pd-list Subject: [PD] Pd-L2Ork [pd~] using real adc
Hi,
So for the [ii] I just added [init] somewhere and now all [ii] are found. No big deal! But I think I have found something a little bit more important (well for me at least):
[pd~ start effectUnitOut.pd< | [pd~ -ninsig 2 -noutsig 2 -fifo 2]
the effectUnitOut.pd [adc~] is using my real adc (of my soundcard) and not the incoming signal~.
hello bug: https://dl.dropboxusercontent.com/u/1455235/pdl2ork_bug.webm
Btw multiple undo rules, à+
Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list