(I have the first part of this running so the decision is one of
design and policy)

We keep PMAX (the variable) small -- actually I would like to reduce
it, but add an extra field to the EVTBLK structure which is a pointer
to an overflow vector, realloc'ed as necessary.

There are two (essentially) uses of p-fields: i events and f events.

In orchestra the reading of pN could be fiddled, or left as it is with
a PMAX limit.

For f events we can manage the additional fields into the FGDATA and
in each gen which can use arbitrary numbers of arguments we just change
the reader of values to switch to the overflow structure.

At present only gen26 can do that (gen26?  Well I invented it to test
the mechanism, ensure fenceposts work etc) but that shows that it is
not hard to ensure.

Advantages:  no limit on pfields for f statements where it makes any
sense.  Very little code shaking.  Would allow us to think of the
alternative designs which take ages to code

Disadvantages: The EVTBLK structure is exposed in the CSOUND structure,
so the API could change unless PMAX is reduced by one pointer's worth
(which differs on 32/64 bit machines but I do know how to fix, albeit
yeaky.
   Requires code adjustment in many parts of fgens,c

Not that a simple change to PMAX will also change to API (evt field)

So any thoughts?  I will continue to test and verify the code, but not
commit it.



==John ffitch

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I think we can adopt the fix with no changes to API (reducing
PMAX by 32 or 64bits and adding the extra pointer) for now.
We can then leave a TODO for when really need next to change
the API for then to try and make significant changes to the
scheme.

Victor

At 12:46 26/08/2009, you wrote:
>(I have the first part of this running so the decision is one of
>design and policy)
>
>We keep PMAX (the variable) small -- actually I would like to reduce
>it, but add an extra field to the EVTBLK structure which is a pointer
>to an overflow vector, realloc'ed as necessary.
>
>There are two (essentially) uses of p-fields: i events and f events.
>
>In orchestra the reading of pN could be fiddled, or left as it is with
>a PMAX limit.
>
>For f events we can manage the additional fields into the FGDATA and
>in each gen which can use arbitrary numbers of arguments we just change
>the reader of values to switch to the overflow structure.
>
>At present only gen26 can do that (gen26?  Well I invented it to test
>the mechanism, ensure fenceposts work etc) but that shows that it is
>not hard to ensure.
>
>Advantages:  no limit on pfields for f statements where it makes any
>sense.  Very little code shaking.  Would allow us to think of the
>alternative designs which take ages to code
>
>Disadvantages: The EVTBLK structure is exposed in the CSOUND structure,
>so the API could change unless PMAX is reduced by one pointer's worth
>(which differs on 32/64 bit machines but I do know how to fix, albeit
>yeaky.
>    Requires code adjustment in many parts of fgens,c
>
>Not that a simple change to PMAX will also change to API (evt field)
>
>So any thoughts?  I will continue to test and verify the code, but not
>commit it.
>
>
>
>==John ffitch
>
>------------------------------------------------------------------------------
>Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
>trial. Simplify your report design, integration and deployment - and focus on
>what you do best, core application coding. Discover what's new with
>Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>_______________________________________________
>Csound-devel mailing list
>Csound-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/csound-devel

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth 


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I have this working now except GENs 32, 51 and 52
Not totally tested as I need examples;think th eAPi is saf ein bothb32 and
64 bit modes
==John

> I think we can adopt the fix with no changes to API (reducing
> PMAX by 32 or 64bits and adding the extra pointer) for now.
> We can then leave a TODO for when really need next to change
> the API for then to try and make significant changes to the
> scheme.
>
> Victor
>
> At 12:46 26/08/2009, you wrote:
>>(I have the first part of this running so the decision is one of
>>design and policy)
>>
>>We keep PMAX (the variable) small -- actually I would like to reduce
>>it, but add an extra field to the EVTBLK structure which is a pointer
>>to an overflow vector, realloc'ed as necessary.
>>
>>There are two (essentially) uses of p-fields: i events and f events.
>>
>>In orchestra the reading of pN could be fiddled, or left as it is with
>>a PMAX limit.
>>
>>For f events we can manage the additional fields into the FGDATA and
>>in each gen which can use arbitrary numbers of arguments we just change
>>the reader of values to switch to the overflow structure.
>>
>>At present only gen26 can do that (gen26?  Well I invented it to test
>>the mechanism, ensure fenceposts work etc) but that shows that it is
>>not hard to ensure.
>>
>>Advantages:  no limit on pfields for f statements where it makes any
>>sense.  Very little code shaking.  Would allow us to think of the
>>alternative designs which take ages to code
>>
>>Disadvantages: The EVTBLK structure is exposed in the CSOUND structure,
>>so the API could change unless PMAX is reduced by one pointer's worth
>>(which differs on 32/64 bit machines but I do know how to fix, albeit
>>yeaky.
>>    Requires code adjustment in many parts of fgens,c
>>
>>Not that a simple change to PMAX will also change to API (evt field)
>>
>>So any thoughts?  I will continue to test and verify the code, but not
>>commit it.
>>
>>
>>
>>==John ffitch
>>
>>------------------------------------------------------------------------------
>>Let Crystal Reports handle the reporting - Free Crystal Reports 2008
>> 30-Day
>>trial. Simplify your report design, integration and deployment - and
>> focus on
>>what you do best, core application coding. Discover what's new with
>>Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>>_______________________________________________
>>Csound-devel mailing list
>>Csound-devel@lists.sourceforge.net
>>https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> Victor Lazzarini
> Music Technology Laboratory
> Music Department
> National University of Ireland, Maynooth
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008
> 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>



------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net