Hi Eric and all,
At 02:41 PM 4/16/98 -0400, Eric Scheirer wrote:
>
>Do you think it will be likely to be close enough to done
>before DIS-time of the standard (October) that we might
>have some bitstream exchanges? This would be a great goal
>to have!
>
This is what I hope, i.e. to have a working real-time unit and at
least a good group of opcodes within the end of september; in July
I will be for sure more precise concerning the expectations for
the Dublin-to-Princeton period.
>
>I have certain comments:
>
>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).
>
> You can't do this in general in SAOL; for example:
>
> aopcode integrate(asig x) {
> asig y;
>
> y = y + x;
> return(y);
> }
>
> 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.
>2. I don't know much about p-code interpretation systems, but
> it seems to me that the right kind of p-code interpreter
> could be very effective for SAOL since you often do most
> of the work in core opcodes. How would we define the
> instruction set for a p-code system for an efficient SAOL
> interpreter?
>
I think this is a good point to be investigated; I see it near to
the problem of efficient metrics for complexity that we are discussing
in the mpeg ad hoc groups. I feel that if we find out a meaningful
complexity vector, at the same time we extract a (possibly)
platform independent virtual machine, which will be a solid starting
point for the p-code instruction set. In the limits of my other
activities, I will try to assign to this task a high priority in the next
weeks.
>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.
>4. What will the front-end be like? Will it just be a command-line
> system like saolc or do you have something better in mind?
>
As a first goal, I'd be happy to have a fine working saol/sasl
decoder in the strict sense of it; in these terms I don't see a great
advantage in having a graphical interface, and anyway it seems easy
to produce one for such a tool; should this software become in the
future the core for an authoring tool, a joint audio/scene decoder or
simply extended to support midi and sound fonts, in this case I
think something better is *necessary*; I have some ideas, but it
will depend a lot on the precise goal.
Thanks for your remarks and discussion starting points,
Giorgio
__________________________________________________________________
Giorgio ZOIA
Integrated Systems Center - DE/c3i - EPFL
CH-1015 Lausanne - SWITZERLAND
Phone: + 41 21 693 69 79 E-mail: Giorgio.Zoia@epfl.ch
Fax: +41 21 693 46 63
__________________________________________________________________
This archive was generated by hypermail 2b29 : Wed May 10 2000 - 12:14:09 EDT