Hi Anthony,

I wasn't aware of the previous conversation but searched my mail box
and found it; it was right around when I was leaving Warsaw so
probably was the furthest thing from my mind.  (The nabble thread is
here: http://www.nabble.com/Re%3A-more-than-one-string-in-an-i-statement-tf3655313.html#a10220997)

The variant type is an ideal solution but I am close to certain it
would require *much* more work than what is mentioned in that thread.
The code in that thread does not take into account that the lookup as
it is now is done per-opcode, not per-instrument.  If we want to do
away with the SSTRCOD and use a union, then we would have to check the
type of the union, then check the type of the of the value it is being
assigned to per expression or opcode arg value.  Currently, opcodes
themselves check for SSTRCOD then get the strarg value.  Ideally,
opcodes would just have char* or MYFLT* or whatever they are
expecting, and the parser itself would hook together correctly and do
type checking there.  If we introduce the variant type but don't do
the changes to opcodes, we're back to using some kind of magic
variable so that the opcode can know its MYFLT * is signifying a
string.

At this point, I'm more and more interested in re-engineering the
engine altogether.   There are a number of STRUCT's that could be
lightened up, memory allocation of instrument instances could change
from the way it pre-allocates a giant block of memory with indexes to
one where it is allocating each part individually (not as efficient
but required for runtime changes to instruments), the maintaining of
variable names to memory addresses (that is all erased currently after
parse time, another factor in disallowing runtime modification of
instruments), etc.  There are also some variables exposed like
curevtblk which opcodes use that makes it impossible to do multi-core
or cluster computation. (There is a related variable that has the
active instrtxt or something like that that goto uses (and thus
if-else and all branching variants) use that also makes
multi-core/cluster impossible).

There are a lot of these types of things that are not small changes.
What does everyone think of starting a new Csound6 branch that will go
ahead and make some pretty big changes and making Csound5 a stable
branch? I think then small changes like new opcodes could go into
Csound5 and perhaps doing the hack suggestion for multiple strings per
score node.  We could outline large scale changes for Csound6 and then
branch that off and start to really aim for that.  If we can outline
the exact changes we want, it should be easy then to target where
we'll go (seems now we're in a bit of a gray area of figuring out
where to go now) and should make it easier for outside developers to
see where we all want to take this and perhaps participate.  Having
the unstable Csound6 branch (or even just making a new repository in
CVS like csound5 is) would also make sure we safely do work there and
not interfere with Csound5 and OLPC and other projects using that.

Thoughts?
steven



On 9/9/07, Anthony Kozar <anthonykozar@sbcglobal.net> wrote:
> Just a note:  I believe that this was discussed a couple of months ago and
> Michael Gogins already suggested a good solution.  Of course, this requires
> modifying the EVTBLK struct.  I pointed out that modifying EVTBLK will break
> API compatibility, and I think we decided to put off this change until a
> time came that we were ready to increase the API major version number
> (presumably because there are other changes to the API that we want to make
> as well).
>
> Anthony Kozar
> anthonykozar AT sbcglobal DOT net
> http://anthonykozar.net/
>
> Steven Yi wrote on 9/9/07 12:53 AM:
>
> > Hi All,
> >
> > I've taken a preliminary look today and it's a bit complicated to find
> > a solution considering the way opcodes are all hooked up together as
> > well as how the magic variable SSTRCOD is used.  (The use of the
> > SSTRCOD is a bit arbitrary in the first place and could in a very
> > remote possibility cause an issue if someone were to use the value.)
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net