[sc-dev] Re: For a more tolerant PlayBuf

[rohan.drape@xxxxxxxxx]

> Actually it would have been nice, but it never worked that way. The
> ugen just failed and didn't try again ...

here (debian/testing/3.7alpha0) it definitely works like
that, & it always has.  sclang codes (set filenames as required):

// Channel mismatch, single channel buffer, two channel playBuf,
// result is silence and channel mismatch message in server log.

{var fn = "/home/rohan/data/audio/pf-c5.aif"
;s.sendMsg("/b_allocRead",0,fn,0,0)}.value

{var sc = BufRateScale.kr(0)
;Out.ar(0,PlayBuf.ar(2,0,sc,1,0,1,0))}.play

// Graph will sound after loading a two channel signal to buffer, and
// stop again after (re-)loading a single channel sound file.

{var fn = "/home/rohan/data/audio/sp/tinguely.aif"
;s.sendMsg("/b_allocRead",0,fn,0,0)}.value

i'm not arguing for the jmcc rule, but it definitley existed!

about the ephemeral nature of supercollider codes: of course it's
fine, it's how the process, and the library design, is.

> (btw. now your mails end up even in a completely different mailbox ...)

the mysteries of slrn...

best,
rohan


_______________________________________________
sc-dev mailing list

info (subscription, etc.): http://www.beast.bham.ac.uk/research/sc_mailing_lists.shtml
archive: https://listarc.bham.ac.uk/marchives/sc-dev/
search: https://listarc.bham.ac.uk/lists/sc-dev/search/