[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Would this be a good case for the rarely seen /cmd? We could turn this functionality and/or a warning on and off.

S.

On 12 Dec 2013, at 18:43, Julian Rohrhuber <julian.rohrhuber@xxxxxxxxxxxxxxxxxx> wrote:

> Hi Josh, thanks for your careful reply.
> 
>> I haven't read the patch yet, but from the standpoint if functionality, this seems problematic to me, an probably incurs more overhead in the code.
> 
> Not really - it incurs one integer comparison per block.
> 
>> The problem is that you have the UGen making decisions for you that you have no power to quickly override. If I play a 4 channel ambisonic file and make the mistake if coding in 2 channels, I will then start to wonder why I seem to have no y and z information coming through, and the 'bug' is that PlayBuf decided to go ahead an work with only the first two channels. I would be looking at my decoders, the original files, etc, and probably not at the source if the problem.
>> With silence, I investigate why my file isn't playing back, and I see a warning in the window.
> 
> We could add a flag that switches on a warning.
> 
> 
>> Many languages return nothing when a function or method with a return is not able to fulfill the return, and that is what PlayBuf is doing.
> 
> You are right, but this is not what SC is usually doing. It rather tends to adjust channel sizes silently by wrapping or omitting, and we all appreciate the flexibility.
> 
>> It makes the problem much easier to find and fix, rather then providing a bandaid that might mask problems further down the signal chain.
> 
> The reason why I started to look at it was that it makes it really complicated to deal with folders with sound files with different channel sizes. It is hard to explain to students, too. I find it inconsistent that you get nothing - whether we should warn or not that is indeed another question.
> 
> In a sense, it is more expensive to have to reload your buffers (spin the hard drive again) when playing back a different number of channels.
> 
>> And like I said, I also imagine the prevention of the read pointers reading off into garbage memory to achieve what you did is more costly CPU wise the. The single check, posting of a warning and the silence return.
> 
> Yes, in the case of using fewer channels, they get zeroed. But this happens all over the ugen library, and doesn't weigh much.
> 
>> Hope that makes sense.
> 
> 
> Yes, it does!
> 
>> One other thing - if you want a 2 channel to play 2 channels of 4 channel file, THAT could be another UGen, and adding a channel offset would make sense as well (give me channels 2 and 3 of this four channel file, for instance). Perhaps take this version if PlayBuf that you have created, give it a new name and add that parameter to the interface and propose that? I would find that UGen very useful and worth the performance hit. Since it would probably mean using less memory in certain situations.
> 
> This is possible, too. Apart from the warning, however, the patch doesn't remove any functionality.
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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/


_______________________________________________
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/