[Robin writes]
> (2) I have repeatedly stated that I believe that Sfx's behaviour wrt/
> sub-guard-rate statements in opcodes in the guarded code block is probably
> non-conformant, and repeatedly stated that I intend to issue a warning or
> error in this case if I can figure out what the correct behaviour is.
And this is why we're having this discussion. I've given my opinion,
you've given yours, Giorgio's giving his opinion, and with any luck
some of the other announced and unannounced decoder writers and other
onlookers will chime in as well. Eric's posting today indicates he's
listening and intends to move the decision-making process to the next
level once we're exhausted.
Be happy, this is what science is supposed to be about -- a defensive
and accusatory approach turns what should be an interesting and
enjoyable process into something that's increasingly unpleasant for me
to participate in with every round (and probably to watch, too). I
trust Eric's judgment to listen and come up with a good approach,
even if its not my personal choice --
> What is Not Explicitly Forbidden is Legal
The problem here is, SAOL isn't (yet) defined with the precision of
(say) the ANSI C standard, where a lot of effort went into nailing
down all the shades of legality. Think of it as a C specification that
isn't quite mature enough to specify that a compiler writer shouldn't
encourage his users to use tricks such as
a ^= b ^= a ^= b;
by opening publishing what his compiler did in this case, and
guaranteeing its future compatibility (for readers who don't recognize
this example, it's a Frequently Asked Question on comp.lang.c, it
tries to modify a variable twice between sequence points and is thus
undefined -- the intent is to swap two variables without an explicit
temporary variable). If you want your users to write code that runs on
other decoders and sounds the same, the right thing to do when you
find a non-explicitly-forbidden thing that looks suspicious is to
bring it up here for discussion, with the hopes of finding a way to
come to a solution we can all implement in a compatible way.
> I'm of the opinion that the conditional branches in a-rate code
> will prevent SAOL from running in realtime.
A data-point: sfront's optimized version of the buzz core opcode has
such if statements in it. I can play more voices of an instrument
based on it than I have fingers, in real-time on my 450 MHz PIII, with
MIDI In from a controller keyboard to my PCI 128 card, running under
Linux, with low latency and lots of mod and pitch wheel usage.
>
> [Robin writes]
>
> Sfx currently evaluates the sub-guard-rate expressions unconditionally.
> [Giorgio writes]
>
> The k-rate expression, if it is broken into intermediate statements
> like in saint, generates a k-block inside the a-rate-guarded block.
> (1) These are not incompatible.
aopcode bar (ksig a)
{
ksig b;
if (!b)
{
b = a;
}
return(aphasor(b) - 0.5);
}
instr foo () {
ksig d;
d = d + 1;
if (d > 100)
{
output(bar(d));
}
}
If the k-rate if statement in bar is executed unconditionally, b is
set to 1, and you get a 1 Hz click train. If the k-rate if statement
in bar is executed conditionally, you get a 100 Hz aliased
sawtooth. Am I misunderstanding something? And if there's an obvious
bug in the above (can't test it since sfront disallows it :-), try
to actually fix the bug to prove my point first ...
--jl
P.S. An addendum to the list of bullets Robin responded too -- the
affect of new UDO semantics on specialops semantics needs to be
considered too. In my physical models that I wrote using the "UDO
rule", the one line I couldn't move out of the instr into an opcode
was the special-op rms() call.
-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------
This archive was generated by hypermail 2b29 : Mon Jan 28 2002 - 12:03:55 EST