DiskIn ugens do not take sampling rate into account #688

Open
timblechmann opened this Issue Dec 11, 2012 · 25 comments

Comments

Projects
None yet
7 participants
Contributor

timblechmann commented Dec 11, 2012

neither DiskIn nor VDiskIn takes the sampling rate of the soundfile into account.

required fixes:

  • enqueing a soundfile via a buffer should update the buffer's sampling rate
  • adapt the UGens to make use of the buffer's sampling rate
Owner

danstowell commented Dec 15, 2012

The API is basically the same as for PlayBuf, for which you need BufRateScale.kr to handle differences in samplerate. So your first "required fix" is needed, but if VDiskIn has its rate controlled by BufRateScale then there's no adaptation needed.

Owner

joshpar commented Dec 15, 2012

This could potentially break code though. We need to find a way to warn users of the change.

On Dec 14, 2012, at 5:20 PM, danstowell notifications@github.com wrote:

The API is basically the same as for PlayBuf, for which you need BufRateScale.kr to handle differences in samplerate. So your first "required fix" is needed, but if VDiskIn has its rate controlled by BufRateScale then there's no adaptation needed.


Reply to this email directly or view it on GitHub.


/* Joshua D. Parmenter
http://www.realizedsound.net/josh/

“Every composer – at all times and in all cases – gives his own interpretation of how modern society is structured: whether actively or passively, consciously or unconsciously, he makes choices in this regard. He may be conservative or he may subject himself to continual renewal; or he may strive for a revolutionary, historical or social palingenesis." - Luigi Nono
*/

Contributor

timblechmann commented Dec 15, 2012

first, i think the ugen should handle the rate scaling, because DiskIn has no rate control, so the semantics of the synth would depend on the sampling rate of the server (maybe it can just become a pseudougen, that wraps VDiskIn with a rate of 1).

the server should probably post a warning, stating that the buffer's sampling rate was changed to match the rate of the sound file ... supernova originally refused to enqueue a file, if the rate does not match, scsynth silently ignored the conflict, probably both should post a warning

Owner

joshpar commented Dec 15, 2012

I'm not entirely sure I agree. DiskIn was made to be as fast as possible, and lets a user have that benefit if they are using the same sample rates, etc. VDiskIn allows for the variety, and is more costly. PlayBuf is the thing that can do whatever you need to do with buffers. I agree about posting a warning.

@joshpar joshpar closed this Dec 15, 2012

@joshpar joshpar reopened this Dec 15, 2012

Owner

joshpar commented Dec 15, 2012

sorry - didn't mean to close.

Contributor

timblechmann commented Dec 15, 2012

VDiskIn could of course use separate ugen functions for an instrument-rate rate argument of 1 ...

btw, imo the BufRateScale.kr ugen adds more overhead than checking the sampling-rate of the buffer inside the ugen function ... we could adapt all buffer ugens and convert BufRateScale.kr to simply return 1 for backwards compatibility ...

Owner

joshpar commented Dec 15, 2012

It's not checking the sampling rate that adds overhead, but the resampling - having a separate function for DiskIn with a rate of 1 would be good as well. But at the same time, this would mean that someone who was running at the incorrect sample-rate will be hit with a performance issue that is unknown to them.

Contributor

timblechmann commented Dec 15, 2012

sure, but the ugen would know if it has to resample or not ... one could do the following methods:

  • instrument-rate, rate == 1: no resampling
  • instrument-rate, rate != 1: resampling, constant playback rate
  • scalar/audio-rate: resampling, allowing modulation of the rate
Owner

joshpar commented Dec 15, 2012

go for it.

Contributor

jamshark70 commented Dec 16, 2012

we could adapt all buffer ugens and convert BufRateScale.kr to simply return 1 for backward compatibility

You don't know that BufRateScale is always feeding into a buffer UGen's rate input. That's the most common usage but it isn't certain. So you couldn't return a scalar 1.0 until you know the ultimate destination of that unit.

It seems to me that this is changing the meaning of the rate input, which is not precisely backward compatible. It may be a valid change but I have to register my opinion that we should tread VERY carefully when changing semantics for the sake of a small optimization. I'd be more comfortable with this proposal if somebody could cite a more compelling reason than speed.

Owner

Sciss commented Dec 16, 2012

I don't see the actual problem. In all my application scenarios I know what the server rate is and what the rate of the sound file is I'm playing, before hand. So there are two use cases: (a) Both are deliberately the same and I don't want to speed up or slow down; this is a very common case. -> Use DiskIn for maximum CPU efficiency. (b) I want to play back arbitrary rate input at arbitrary rate output. -> I calculate the rate and run VDiskIn. And when too lazy, I let the server do that with BufRateScale. So what is it that you are trying to solve? I wouldn't touch the semantics of the UGens without urge.

Contributor

timblechmann commented Dec 16, 2012

sciss:

  • why have a concept of BufRateScale in the first place? it is just noise that you have to write and which is completely unrelated to the musical ideas that you want to express.
  • there are people, who do not use a fixed sampling rate (for my last composition, i used 48khz when working on a 64speaker array, 96 when working in my studio and the final files are rendered in 3072khz)
Owner

Sciss commented Dec 16, 2012

I don't think of UGens as a direct embodiment of musical ideas, but as precise DSP building blocks. The 'interpretation' can come on a higher level. I have no problem if you add another 'musical' pseudo-ugen for this, but I don't see any benefit adding complexity to the server side and at the same time breaking old code (and yes, I use a different client, so patches in the SCClassLibrary don't help me). I have encountered those changes multiple times, and they are serious sources of errors in my opinion; you can exchange the different client for a stored SynthDef file if you like, then you see what problems are introduced by changing the meaning of UGens.

Of course, the overall theme would be how to deal with backward compatibility in a sensible manner. I don't think that re-adjusting the UGen .sc class files is a proper solution.

Regarding your example: Are you imagining using DiskIn instead of VDiskIn for this? If not, what is the difference of adding the multiplication factor to your VDiskIn inputs. I assume you know at what sample rate you launch your server?

Contributor

jamshark70 commented Dec 16, 2012

I'm just going to state my opinion again:

  • Please, let's not change the buffer UGens' API in 3.6. If we are considering 3.6.1, 3.6.2, 3.6.x to be bugfix releases, then it seems pretty obvious to me that changing a UGen's semantics is not a candidate to include in a bugfix release.
  • I would even be skeptical about changing this in any 3.x version, because it has worked one way in all 3.x's and it's reasonable for users to expect something so basic to be stable within a major version.
  • There has been talk about making SC4 the version that cleans up API weaknesses, inconsistencies and the like. If so, I think that would be the vehicle to change how PlayBuf and cousins operate.
  • I don't think it's a good idea to make BufRateScale return 1 (certainly not in a bugfix release). As I said earlier, BufRateScale is most commonly used for a rate input, but there's no guarantee that it will always be used that way.
Owner

danstowell commented Dec 16, 2012

I agree that many users don't want to be concerned with the sampling rate, but I agree with sciss that it's quite common to deliberately use soundfiles matching the sampling rate during production, which is good for cpu and for sound quality because it avoids all resampling.

I don't think the API should change because it's such a core thing used by so many. A backward-compatible option might be: if "rate" is given as scalar 0 (not ar or kr), that's when it resamples.

Owner

Sciss commented Dec 16, 2012

I like the scalar 0, that sounds like a sensible thing to do. Sorry to ask again -- so we are only talking about VDiskIn, right? So in any case, DiskIn would not get automatic resampling?

Contributor

timblechmann commented Dec 16, 2012

of course, the cleanest approach is to do an SC4 in order to clean up old cruft ... also buffer handling in FFTs could be changed by implicitly creating a local buffer ...

imo DiskIn should disappear, but VDiskIn should not resample under the conditions mentioned above. iac, ugens do not live on their own, but they have parts in the server and parts in the class library. i know this is controversial and people will hate me for saying this, but using other languages with scsynth is not officially supported. and keeping compatibility forever is simply slowing down development to a point that completely stops all further development.

Owner

Sciss commented Dec 16, 2012

Well, then please tell me what the definition of officially supported is? All I can see is that there are a bunch of people who are doing great things with Haskell, Clojure, Scala, Python, Inpromptu and what have you. The advantage of SC3 has always been a rather clear separation of the API facades of client and server, and therefore I will always fight for that separation.

"Fixes" like this do not speed up development at all, so do not tell me it is a burden not to break VDiskIn. I'm all for progress, but it needs careful planning. Any big system, any big language or library, has a semantic versioning approach which deals with compatibility. It is a burden, but it is a necessity to go beyond the short term goals and look at the bigger picture, otherwise you are speaking for a personal project driven by your convenience and not that of others (including minorities).

Contributor

timblechmann commented Dec 16, 2012

using scsynth from sclang is officially supported. in general, i'm in favor of a design to do only one thing, but to do this right, instead of supporting many things in a fragile way ...

Contributor

jamshark70 commented Dec 16, 2012

Stating it non-confrontationally: In one of the list discussions, I think it was Jonatan who suggested the idea of SC4 as the "non-backward-compatible" version, where users would know up front that upgrading to this version would mean rewriting old code. I actually think this is a good idea.

That implies, however, that SC3.x versions will attempt to maintain compatibility as much as possible. And I think SC3.x should try to keep compatibility.

I'm absolutely not opposed to progress that breaks compatibility but, such progress needs to be made in the proper vehicle.

Instead of messing around with VDiskIn, PlayBuf etc. in 3.x, I think it would be better to start a wiki section or forum now to start gathering requirements for cleaner SC4 APIs. I would find this more convincing than complaining about the shackles of backward compatibility.

Owner

Sciss commented Dec 16, 2012

James, I agree. I also would not be opposed to changes in a major version bump, given that we maintain a clear document which has entries for each change (irrespective of whether that change is invisible due to counter measures in SCClassLibrary)

  • Which UGens were removed physically. How to work around that
  • Which UGens gained extra arguments or extra functionality depending on special argument values
  • Which UGen argument inputs meaning changed.

That way clients can update in a systematic manner, and are not required to follow issue trackers or discussions to accidentally learn that something subtle changed.

Such a document would be very valuable not just for users of other clients, but also for music pieces or research projects which can easily get several years of history and then may need adjustment because there are no old machines which run the old SC versions. So this is exactly preventing fragility which is otherwise introduced because of wrong assumptions (SynthDefs getting re-generated through SCClassLibrary).

Contributor

timblechmann commented Dec 16, 2012

sciss, do you volunteer to maintain such a document? sam aaron had the same request during the last symposium and i suppose victor (lua) and stefan (haskell) might be interested as well ... so maybe you can all form an alliance to make sure that such a document stays up to date ...

Owner

Sciss commented Dec 16, 2012

Yes, absolutely. The only problem I have at the moment is that I'm still on an OS X 10.6 machine with no near future possibility of upgrading, so I actually haven't built SC from source since a year, I hope it's still possible with the versions of dev tools on this machine. In any case I could check out the repository and create that document.

Contributor

timblechmann commented Dec 16, 2012

iirc the binaries on sourceforge are compiled for 10.5

Contributor

muellmusik commented Dec 16, 2012

I've also been suggesting an SC4 as being a major cleanup and redesign release (hopefully in addition to other things!) for awhile now. I think such a project is long overdue, and in keeping with SC's tradition of epochal rethinks. Also, given that the SC community is unusually averse to deprecation, it may be the only way to do it practically.

For the topic at hand though, and given that I'm sympathetic to Tim's points, how about a bridging approach:

A new super DiskIn UGen now, with the desired features (playing backwards as well, since we're at it, please!), which would survive into SC4, but keep the existing ones in the meantime. That provides a sunset clause for the maintenance issue.

@telephon telephon added this to the future milestone May 19, 2016

@telephon telephon added enhancement API change and removed bug labels May 19, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment