Hi all,
in the last few months I have been paying attention to the developments
in saol, csound, and the like. I would like to give a couple of humble
viewpoints on the open points you raised.
Giorgio Zoia wrote:
> >1. The issue of block-structured execution vs sample-structured
> > execution is a difficult one. Csound gets a lot of its
> > speed from executing block-by-block (you only have to
> > figure out what to do once per k-cycle, then do that N times,
> > rather than figuring out what to do N times per cycle).
...
> >
> > has to operate sample-by-sample to work right. Is there a
> > good way to make this work on a block-by-block basis? If
> > not, can we "figure out" which parts may work block-by-block
> > and do as many of those as we can, and then work sample-by-
> > sample on the others?
> >
>
> I don't see at the moment if an easy solution exists in general, this case
> could for instance be solved at the price of some extra memory allocation,
> but probably I must also consider how and where the opcode is called, if
> there are other relations at the a-rate between x and y, etc.
> Anyway at the moment what I am trying to understand is the "frequency"
> at which the scheduler will work, i.e. if it is wise to have a block every
> k-cycle. For example, I see this block as a delay between input and output
> in the case of AudioFX node: I am not able to find out, in the mpeg cd,
> in which way a tree "sources->fxs->mix->sound" is constrained in terms
> of delay and synchronization. From the cd I have it seems that the last
> synch check and time check are at the composition buffer of the sources...
> Is it like that ? I hope not.
I think that the distinction between a-rate and k-rate is a serious
semantic problem in csound and saol. This immediately appears when one
tries to write his own digital filter without using the predefined
blocks: the results are likely to be correct only if s-rate = k-rate. I
don't think this behavior is desirable, because it means that the
semantics is highly dependent on the s/k ratio. This ratio should only
affects efficiency and quality of results, not the correctness of the
results themselves. Languages such as CLM are don't make the distinction
k-rate vs a-rate, and therefore the user is free to neglect this issue
when designing the algorithms. Still, I think that some efficiency might
be gained from distinguishing k-rate from a-rate without doing block
computation, if we just execute the operations for k-variables every a/k
samples. This might save time for envelopes or LFOs.
>
> >3. Perhaps the core-opcode architecture could be more open so
> > that people who want to come up with very fast CO's could
> > work on them and give them to you. I was going to do this
> > for saolc, but there's so much overhead in saolc that
> > CO's are usually only about 4% of the work.
> >
>
> I see no problem for such an approach, once the software architecture
> of the decoder will be well defined.
I would like to see only a small set of significant primitives, thus
avoiding the jungle of versions such as in csound. I have some ideas
about what should be there and I would be pleased to share them if
needed.
This projects looks very promising, keep up the good work.
d
+----------------------------------------------+
Davide Rocchesso
Ist. Policattedra - Fac. di Scienze
Strada Le Grazie - 37134 Verona (IT)
Tel. (+39)(0)45-8098979
Fax. (+39)(0)45-8098928
e-mail: rocchesso@sci.univr.it
http://www.dei.unipd.it/ricerca/csc/people/roc
+ ---------------------------------------------+
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:14:09 EDT