[sc-users] Re: string formatting notation

[jamshark70@xxxxxx]

>> We haven't relayed the call
>> to sprintf() because of the risk of crashing the language with bad input.
> 
> asStringPrec uses sprintf() under the hood. There is absolutely no reason
> not to make it available, as long as you know how to avoid a buffer
> overrun.

The difference is, in asStringPrec, sclang's C code has total control over
the format string, and it can guarantee validity and avoid crashes. When JMc
added .format(), he did not open up C-style formatting strings because the
*user* provides the format string, making it impossible for the C code to be
sure sprintf() wouldn't crash.

SC's error handling is a lot more solid now, so it may be feasible to wrap
sprintf() in a try block so that failure produces an error in the language,
rather than crashing the sclang process. Nobody has investigated this, but
you would have to do this to make it viable. It isn't sufficient only to
avoid a buffer overrun.


> But, I find it funny that you think giving access to gnarly printf-style
> format strings over this notation is worth it. (What does "f+0.8%" do
> again?)

I do realize that's inconsistent with my concerns about legibility... but,
it would be a minimal change of interface to gain a vast amount of
functionality basically for free -- and, an established vast amount of
functionality with decades of testing behind it, instead of us trying to
roll something new that would certainly introduce bugs.

I'm not /a priori/ opposed to embedding code within strings -- this is, in
fact, how my live-coding framework supports generator functions.

/snare = "|-| \ins("", "-", 1, 0.5)|";

A concrete benefit is that the generator -- \ins() -- knows the time span
within the bar over which is allowed to operate (here, beat 3.5 - end of
bar) based on its position within the string. The embedding is not merely
for convenience; it conveys musical information to the downstream object,
and the way it does this is closely related to the way (Western) musicians
think about meter. So I get crucial functional information in a way that's
more intuitive to manipulate in performance than, say, Pseq-ing subpatterns.

I'm not certain that the benefit of string interpolation is quite this
significant. But I'm open enough to the idea to spend an hour this morning
prototyping it, so I can try it out, see how it feels for myself.

hjh



--
Sent from: http://new-supercollider-mailing-lists-forums-use-these.2681727.n2.nabble.com/SuperCollider-Users-New-Use-this-f2676391.html

_______________________________________________
sc-users mailing list

info (subscription, etc.): http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
archive: https://listarc.bham.ac.uk/marchives/sc-users/
search: https://listarc.bham.ac.uk/lists/sc-users/search/