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: [email protected] [mailto:[email protected]] On Behalf Of
> [email protected]
> 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,
> à+
> 
> _______________________________________________
> [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

Reply via email to