Hi All,

Just another status update: I have replaced the use of variable counts
with CS_VARIABLE's and VAR_POOL.  This involved also changing how arg
indexes were handled (I am using a new ARG* struct that contains a
reference to a CS_VAR or an index).  Doing this also removed the magic
number work for args (i.e. positive is global, negative is local, but
if > than some limit it's a string, etc.).  I had somewhat of a
breakthrough just now in that I was able to run a simple CSD.

I have to fix usage of labels (will be changing how labels are stored
globally in CSOUND* and moving that to INSTRTXT), as well rework
string constants (mostly done, just need to sense and hookup in memory
in the STRING_POOL).  Understanding and modifying
instance/otran/insprep took quite a while, but I think I've got a
handle on it now and am moving forward.

If curious, I've pushed my latest code changes to the csound6
typesystem branch. It is very untidy at the moment, as there is a lot
of commented out code and FIXME reminders for myself.  Those will be
cleaned up by the time this is complete.

Will update as things continue, thanks!
steven

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Sounds good, it really looks like good progress there.

Victor
On 30 Jul 2012, at 22:59, Steven Yi wrote:

> Hi All,
> 
> Just another status update: I have replaced the use of variable counts
> with CS_VARIABLE's and VAR_POOL.  This involved also changing how arg
> indexes were handled (I am using a new ARG* struct that contains a
> reference to a CS_VAR or an index).  Doing this also removed the magic
> number work for args (i.e. positive is global, negative is local, but
> if > than some limit it's a string, etc.).  I had somewhat of a
> breakthrough just now in that I was able to run a simple CSD.
> 
> I have to fix usage of labels (will be changing how labels are stored
> globally in CSOUND* and moving that to INSTRTXT), as well rework
> string constants (mostly done, just need to sense and hookup in memory
> in the STRING_POOL).  Understanding and modifying
> instance/otran/insprep took quite a while, but I think I've got a
> handle on it now and am moving forward.
> 
> If curious, I've pushed my latest code changes to the csound6
> typesystem branch. It is very untidy at the moment, as there is a lot
> of commented out code and FIXME reminders for myself.  Those will be
> cleaned up by the time this is complete.
> 
> Will update as things continue, thanks!
> steven
> 
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and 
> threat landscape has changed and how IT managers can respond. Discussions 
> will include endpoint security, mobile security and the latest in malware 
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

Dr Victor Lazzarini
Senior Lecturer
Dept. of Music
NUI Maynooth Ireland
tel.: +353 1 708 3545
Victor dot Lazzarini AT nuim dot ie




------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Yes, things are going nicely!

Another update: I've gotten labels and PFields now working.  I've
changed label lookup in instance to use the recorded label name in the
ARG* and search through the opcode chain for the corresponding LABEL
opcode with the opnam of the label.  I imagine it's a bit slower than
the previous implementation; certainly this can be optimized.  Also,
the space allocated for bools was fixed to a size of MYFLT instead of
int.  (Latest pushed to SourceForge.)

I'm seeing one issue now with the design in that memblock sizes for
variables is being calculated too early, before CSOUND* has been
updated with the values from the CSD.  Consequently, currently a-var's
are reporting memblock size of 10 * sizeof(MYFLT).  I'm going to work
on fixing that up tomorrow.  I still need to work out string pool
stuff as well, but all coming along.

Thanks!
steven



On Tue, Jul 31, 2012 at 5:55 AM, Victor Lazzarini
 wrote:
> Sounds good, it really looks like good progress there.
>
> Victor
> On 30 Jul 2012, at 22:59, Steven Yi wrote:
>
>> Hi All,
>>
>> Just another status update: I have replaced the use of variable counts
>> with CS_VARIABLE's and VAR_POOL.  This involved also changing how arg
>> indexes were handled (I am using a new ARG* struct that contains a
>> reference to a CS_VAR or an index).  Doing this also removed the magic
>> number work for args (i.e. positive is global, negative is local, but
>> if > than some limit it's a string, etc.).  I had somewhat of a
>> breakthrough just now in that I was able to run a simple CSD.
>>
>> I have to fix usage of labels (will be changing how labels are stored
>> globally in CSOUND* and moving that to INSTRTXT), as well rework
>> string constants (mostly done, just need to sense and hookup in memory
>> in the STRING_POOL).  Understanding and modifying
>> instance/otran/insprep took quite a while, but I think I've got a
>> handle on it now and am moving forward.
>>
>> If curious, I've pushed my latest code changes to the csound6
>> typesystem branch. It is very untidy at the moment, as there is a lot
>> of commented out code and FIXME reminders for myself.  Those will be
>> cleaned up by the time this is complete.
>>
>> Will update as things continue, thanks!
>> steven
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: +353 1 708 3545
> Victor dot Lazzarini AT nuim dot ie
>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Where is the code?  I am not seeing it in git.  I was hoping to work on
loadable instruments v=but I suspect this overlaps what you are dong
==John

> Yes, things are going nicely!
>
> Another update: I've gotten labels and PFields now working.  I've
> changed label lookup in instance to use the recorded label name in the
> ARG* and search through the opcode chain for the corresponding LABEL
> opcode with the opnam of the label.  I imagine it's a bit slower than
> the previous implementation; certainly this can be optimized.  Also,
> the space allocated for bools was fixed to a size of MYFLT instead of
> int.  (Latest pushed to SourceForge.)
>
> I'm seeing one issue now with the design in that memblock sizes for
> variables is being calculated too early, before CSOUND* has been
> updated with the values from the CSD.  Consequently, currently a-var's
> are reporting memblock size of 10 * sizeof(MYFLT).  I'm going to work
> on fixing that up tomorrow.  I still need to work out string pool
> stuff as well, but all coming along.
>
> Thanks!
> steven
>
>
>
> On Tue, Jul 31, 2012 at 5:55 AM, Victor Lazzarini
>  wrote:
>> Sounds good, it really looks like good progress there.
>>
>> Victor
>> On 30 Jul 2012, at 22:59, Steven Yi wrote:
>>
>>> Hi All,
>>>
>>> Just another status update: I have replaced the use of variable counts
>>> with CS_VARIABLE's and VAR_POOL.  This involved also changing how arg
>>> indexes were handled (I am using a new ARG* struct that contains a
>>> reference to a CS_VAR or an index).  Doing this also removed the magic
>>> number work for args (i.e. positive is global, negative is local, but
>>> if > than some limit it's a string, etc.).  I had somewhat of a
>>> breakthrough just now in that I was able to run a simple CSD.
>>>
>>> I have to fix usage of labels (will be changing how labels are stored
>>> globally in CSOUND* and moving that to INSTRTXT), as well rework
>>> string constants (mostly done, just need to sense and hookup in memory
>>> in the STRING_POOL).  Understanding and modifying
>>> instance/otran/insprep took quite a while, but I think I've got a
>>> handle on it now and am moving forward.
>>>
>>> If curious, I've pushed my latest code changes to the csound6
>>> typesystem branch. It is very untidy at the moment, as there is a lot
>>> of commented out code and FIXME reminders for myself.  Those will be
>>> cleaned up by the time this is complete.
>>>
>>> Will update as things continue, thanks!
>>> steven
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond.
>>> Discussions
>>> will include endpoint security, mobile security and the latest in
>>> malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> Dr Victor Lazzarini
>> Senior Lecturer
>> Dept. of Music
>> NUI Maynooth Ireland
>> tel.: +353 1 708 3545
>> Victor dot Lazzarini AT nuim dot ie
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond.
>> Discussions
>> will include endpoint security, mobile security and the latest in
>> malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>



------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi John,

The changes are in a branch called typesystem.  If you don't have the
branch locally, you should be able to set it up by calling:

git checkout -t origin/typesystem

After that, you can switch between master and typesystem by just:

git checkout master
git checkout typesystem

Note, there's still some things to do.  One aspect of these changes is
to make csound more amenable to dynamic loading.  For example, moving
labels to be just local to an instrument instead of being held in
CSOUND* so that data doesn't hang around if an instrument is deleted.
Also introducing a rule for a full semantic check pass before doing
compiling to INSTRTXT prevent destructive edits to CSOUND state (no
need to compile a new instrument and start modifying CSOUND if it's
going to cause a type error). The current implementation also keeps
around variable names, so if new instruments are going to be loaded
during a run, they can lookup the mem addresses of global vars.

Also for modification of an instrument it should be easier due to
variables being tracked in a pool, meaning we could add new variables
of any type to the pool and realloc the memory allocated for the
instances.

However, oload and insprep still has code that assumes no
modifications during a run, such as allocating the global memory pool
and other pools.  Those will need to be moved to another location or
be done only if the pool pointers are NULL to start.

Thanks!
steven

On Wed, Aug 1, 2012 at 6:08 AM,   wrote:
> Where is the code?  I am not seeing it in git.  I was hoping to work on
> loadable instruments v=but I suspect this overlaps what you are dong
> ==John
>
>> Yes, things are going nicely!
>>
>> Another update: I've gotten labels and PFields now working.  I've
>> changed label lookup in instance to use the recorded label name in the
>> ARG* and search through the opcode chain for the corresponding LABEL
>> opcode with the opnam of the label.  I imagine it's a bit slower than
>> the previous implementation; certainly this can be optimized.  Also,
>> the space allocated for bools was fixed to a size of MYFLT instead of
>> int.  (Latest pushed to SourceForge.)
>>
>> I'm seeing one issue now with the design in that memblock sizes for
>> variables is being calculated too early, before CSOUND* has been
>> updated with the values from the CSD.  Consequently, currently a-var's
>> are reporting memblock size of 10 * sizeof(MYFLT).  I'm going to work
>> on fixing that up tomorrow.  I still need to work out string pool
>> stuff as well, but all coming along.
>>
>> Thanks!
>> steven
>>
>>
>>
>> On Tue, Jul 31, 2012 at 5:55 AM, Victor Lazzarini
>>  wrote:
>>> Sounds good, it really looks like good progress there.
>>>
>>> Victor
>>> On 30 Jul 2012, at 22:59, Steven Yi wrote:
>>>
>>>> Hi All,
>>>>
>>>> Just another status update: I have replaced the use of variable counts
>>>> with CS_VARIABLE's and VAR_POOL.  This involved also changing how arg
>>>> indexes were handled (I am using a new ARG* struct that contains a
>>>> reference to a CS_VAR or an index).  Doing this also removed the magic
>>>> number work for args (i.e. positive is global, negative is local, but
>>>> if > than some limit it's a string, etc.).  I had somewhat of a
>>>> breakthrough just now in that I was able to run a simple CSD.
>>>>
>>>> I have to fix usage of labels (will be changing how labels are stored
>>>> globally in CSOUND* and moving that to INSTRTXT), as well rework
>>>> string constants (mostly done, just need to sense and hookup in memory
>>>> in the STRING_POOL).  Understanding and modifying
>>>> instance/otran/insprep took quite a while, but I think I've got a
>>>> handle on it now and am moving forward.
>>>>
>>>> If curious, I've pushed my latest code changes to the csound6
>>>> typesystem branch. It is very untidy at the moment, as there is a lot
>>>> of commented out code and FIXME reminders for myself.  Those will be
>>>> cleaned up by the time this is complete.
>>>>
>>>> Will update as things continue, thanks!
>>>> steven
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond.
>>>> Discussions
>>>> will include endpoint security, mobile security and the latest in
>>>> malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> Dr Victor Lazzarini
>>> Senior Lecturer
>>> Dept. of Music
>>> NUI Maynooth Ireland
>>> tel.: +353 1 708 3545
>>> Victor dot Lazzarini AT nuim dot ie
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond.
>>> Discussions
>>> will include endpoint security, mobile security and the latest in
>>> malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>
>>
>>
>
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Update: I've managed to fix up the issue with memblock calculations by
adding a recalculateVarPoolMemory function that is called after ksmps
is set in CSOUND (pushed to GIT).  I'm working on handling string args
(having to reinstate set_xincod and set_xoutcod).  I see an issue with
memblock calculations for ksmps and UDO's, in that UDO's can have
setksmps. I think this might be an opportunity to finally remove the
ksmps hack for UDO's where it modifies the CSOUND*.  I'm not sure yet
what's the way forward with that, but regardless it will require an
overhaul of opcodes to lookup ksmps not from CSOUND itself but rather
from a CONTEXT struct or somewhere else that is set on the OPDS.

Thanks,
steven

On Wed, Aug 1, 2012 at 9:42 AM, Steven Yi  wrote:
> Hi John,
>
> The changes are in a branch called typesystem.  If you don't have the
> branch locally, you should be able to set it up by calling:
>
> git checkout -t origin/typesystem
>
> After that, you can switch between master and typesystem by just:
>
> git checkout master
> git checkout typesystem
>
> Note, there's still some things to do.  One aspect of these changes is
> to make csound more amenable to dynamic loading.  For example, moving
> labels to be just local to an instrument instead of being held in
> CSOUND* so that data doesn't hang around if an instrument is deleted.
> Also introducing a rule for a full semantic check pass before doing
> compiling to INSTRTXT prevent destructive edits to CSOUND state (no
> need to compile a new instrument and start modifying CSOUND if it's
> going to cause a type error). The current implementation also keeps
> around variable names, so if new instruments are going to be loaded
> during a run, they can lookup the mem addresses of global vars.
>
> Also for modification of an instrument it should be easier due to
> variables being tracked in a pool, meaning we could add new variables
> of any type to the pool and realloc the memory allocated for the
> instances.
>
> However, oload and insprep still has code that assumes no
> modifications during a run, such as allocating the global memory pool
> and other pools.  Those will need to be moved to another location or
> be done only if the pool pointers are NULL to start.
>
> Thanks!
> steven
>
> On Wed, Aug 1, 2012 at 6:08 AM,   wrote:
>> Where is the code?  I am not seeing it in git.  I was hoping to work on
>> loadable instruments v=but I suspect this overlaps what you are dong
>> ==John
>>
>>> Yes, things are going nicely!
>>>
>>> Another update: I've gotten labels and PFields now working.  I've
>>> changed label lookup in instance to use the recorded label name in the
>>> ARG* and search through the opcode chain for the corresponding LABEL
>>> opcode with the opnam of the label.  I imagine it's a bit slower than
>>> the previous implementation; certainly this can be optimized.  Also,
>>> the space allocated for bools was fixed to a size of MYFLT instead of
>>> int.  (Latest pushed to SourceForge.)
>>>
>>> I'm seeing one issue now with the design in that memblock sizes for
>>> variables is being calculated too early, before CSOUND* has been
>>> updated with the values from the CSD.  Consequently, currently a-var's
>>> are reporting memblock size of 10 * sizeof(MYFLT).  I'm going to work
>>> on fixing that up tomorrow.  I still need to work out string pool
>>> stuff as well, but all coming along.
>>>
>>> Thanks!
>>> steven
>>>
>>>
>>>
>>> On Tue, Jul 31, 2012 at 5:55 AM, Victor Lazzarini
>>>  wrote:
>>>> Sounds good, it really looks like good progress there.
>>>>
>>>> Victor
>>>> On 30 Jul 2012, at 22:59, Steven Yi wrote:
>>>>
>>>>> Hi All,
>>>>>
>>>>> Just another status update: I have replaced the use of variable counts
>>>>> with CS_VARIABLE's and VAR_POOL.  This involved also changing how arg
>>>>> indexes were handled (I am using a new ARG* struct that contains a
>>>>> reference to a CS_VAR or an index).  Doing this also removed the magic
>>>>> number work for args (i.e. positive is global, negative is local, but
>>>>> if > than some limit it's a string, etc.).  I had somewhat of a
>>>>> breakthrough just now in that I was able to run a simple CSD.
>>>>>
>>>>> I have to fix usage of labels (will be changing how labels are stored
>>>>> globally in CSOUND* and moving that to INSTRTXT), as well rework
>>>>> string constants (mostly done, just need to sense and hookup in memory
>>>>> in the STRING_POOL).  Understanding and modifying
>>>>> instance/otran/insprep took quite a while, but I think I've got a
>>>>> handle on it now and am moving forward.
>>>>>
>>>>> If curious, I've pushed my latest code changes to the csound6
>>>>> typesystem branch. It is very untidy at the moment, as there is a lot
>>>>> of commented out code and FIXME reminders for myself.  Those will be
>>>>> cleaned up by the time this is complete.
>>>>>
>>>>> Will update as things continue, thanks!
>>>>> steven
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Live Security Virtual Conference
>>>>> Exclusive live event will cover all the ways today's security and
>>>>> threat landscape has changed and how IT managers can respond.
>>>>> Discussions
>>>>> will include endpoint security, mobile security and the latest in
>>>>> malware
>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>> Dr Victor Lazzarini
>>>> Senior Lecturer
>>>> Dept. of Music
>>>> NUI Maynooth Ireland
>>>> tel.: +353 1 708 3545
>>>> Victor dot Lazzarini AT nuim dot ie
>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond.
>>>> Discussions
>>>> will include endpoint security, mobile security and the latest in
>>>> malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>
>>>
>>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hi All,

I managed to get string args working (committed to GIT).  I added back
in set_xincod and set_xoutcod but commented out the type checking
parts that used the old otran global stuff, and left in the parts that
set xincod for strings.  Strings now seem to be working as args to
opcodes.

Note:  I'll be taking a look at this off and on, but will likely not
focus on this again until I get back to Ireland at the end of August.
(Lot going on right now: new Csound Journal issue editing, moving,
travels, presentations, etc.)

I think next steps are to merge the latest changes from master to
typesystem branch so it doesn't stray too far, then move forward with
some bigger changes, namely the modifications for ksmps so that the
hack used in calling UDO's can be removed.  Also, t-sigs currently are
not added back in, as my plan to implement arrays generically so that
arrays of any types could be created.

Thanks!
steven


On Wed, Aug 1, 2012 at 7:35 PM, Steven Yi  wrote:
> Update: I've managed to fix up the issue with memblock calculations by
> adding a recalculateVarPoolMemory function that is called after ksmps
> is set in CSOUND (pushed to GIT).  I'm working on handling string args
> (having to reinstate set_xincod and set_xoutcod).  I see an issue with
> memblock calculations for ksmps and UDO's, in that UDO's can have
> setksmps. I think this might be an opportunity to finally remove the
> ksmps hack for UDO's where it modifies the CSOUND*.  I'm not sure yet
> what's the way forward with that, but regardless it will require an
> overhaul of opcodes to lookup ksmps not from CSOUND itself but rather
> from a CONTEXT struct or somewhere else that is set on the OPDS.
>
> Thanks,
> steven
>
> On Wed, Aug 1, 2012 at 9:42 AM, Steven Yi  wrote:
>> Hi John,
>>
>> The changes are in a branch called typesystem.  If you don't have the
>> branch locally, you should be able to set it up by calling:
>>
>> git checkout -t origin/typesystem
>>
>> After that, you can switch between master and typesystem by just:
>>
>> git checkout master
>> git checkout typesystem
>>
>> Note, there's still some things to do.  One aspect of these changes is
>> to make csound more amenable to dynamic loading.  For example, moving
>> labels to be just local to an instrument instead of being held in
>> CSOUND* so that data doesn't hang around if an instrument is deleted.
>> Also introducing a rule for a full semantic check pass before doing
>> compiling to INSTRTXT prevent destructive edits to CSOUND state (no
>> need to compile a new instrument and start modifying CSOUND if it's
>> going to cause a type error). The current implementation also keeps
>> around variable names, so if new instruments are going to be loaded
>> during a run, they can lookup the mem addresses of global vars.
>>
>> Also for modification of an instrument it should be easier due to
>> variables being tracked in a pool, meaning we could add new variables
>> of any type to the pool and realloc the memory allocated for the
>> instances.
>>
>> However, oload and insprep still has code that assumes no
>> modifications during a run, such as allocating the global memory pool
>> and other pools.  Those will need to be moved to another location or
>> be done only if the pool pointers are NULL to start.
>>
>> Thanks!
>> steven
>>
>> On Wed, Aug 1, 2012 at 6:08 AM,   wrote:
>>> Where is the code?  I am not seeing it in git.  I was hoping to work on
>>> loadable instruments v=but I suspect this overlaps what you are dong
>>> ==John
>>>
>>>> Yes, things are going nicely!
>>>>
>>>> Another update: I've gotten labels and PFields now working.  I've
>>>> changed label lookup in instance to use the recorded label name in the
>>>> ARG* and search through the opcode chain for the corresponding LABEL
>>>> opcode with the opnam of the label.  I imagine it's a bit slower than
>>>> the previous implementation; certainly this can be optimized.  Also,
>>>> the space allocated for bools was fixed to a size of MYFLT instead of
>>>> int.  (Latest pushed to SourceForge.)
>>>>
>>>> I'm seeing one issue now with the design in that memblock sizes for
>>>> variables is being calculated too early, before CSOUND* has been
>>>> updated with the values from the CSD.  Consequently, currently a-var's
>>>> are reporting memblock size of 10 * sizeof(MYFLT).  I'm going to work
>>>> on fixing that up tomorrow.  I still need to work out string pool
>>>> stuff as well, but all coming along.
>>>>
>>>> Thanks!
>>>> steven
>>>>
>>>>
>>>>
>>>> On Tue, Jul 31, 2012 at 5:55 AM, Victor Lazzarini
>>>>  wrote:
>>>>> Sounds good, it really looks like good progress there.
>>>>>
>>>>> Victor
>>>>> On 30 Jul 2012, at 22:59, Steven Yi wrote:
>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>> Just another status update: I have replaced the use of variable counts
>>>>>> with CS_VARIABLE's and VAR_POOL.  This involved also changing how arg
>>>>>> indexes were handled (I am using a new ARG* struct that contains a
>>>>>> reference to a CS_VAR or an index).  Doing this also removed the magic
>>>>>> number work for args (i.e. positive is global, negative is local, but
>>>>>> if > than some limit it's a string, etc.).  I had somewhat of a
>>>>>> breakthrough just now in that I was able to run a simple CSD.
>>>>>>
>>>>>> I have to fix usage of labels (will be changing how labels are stored
>>>>>> globally in CSOUND* and moving that to INSTRTXT), as well rework
>>>>>> string constants (mostly done, just need to sense and hookup in memory
>>>>>> in the STRING_POOL).  Understanding and modifying
>>>>>> instance/otran/insprep took quite a while, but I think I've got a
>>>>>> handle on it now and am moving forward.
>>>>>>
>>>>>> If curious, I've pushed my latest code changes to the csound6
>>>>>> typesystem branch. It is very untidy at the moment, as there is a lot
>>>>>> of commented out code and FIXME reminders for myself.  Those will be
>>>>>> cleaned up by the time this is complete.
>>>>>>
>>>>>> Will update as things continue, thanks!
>>>>>> steven
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Live Security Virtual Conference
>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>> threat landscape has changed and how IT managers can respond.
>>>>>> Discussions
>>>>>> will include endpoint security, mobile security and the latest in
>>>>>> malware
>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>> Dr Victor Lazzarini
>>>>> Senior Lecturer
>>>>> Dept. of Music
>>>>> NUI Maynooth Ireland
>>>>> tel.: +353 1 708 3545
>>>>> Victor dot Lazzarini AT nuim dot ie
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Live Security Virtual Conference
>>>>> Exclusive live event will cover all the ways today's security and
>>>>> threat landscape has changed and how IT managers can respond.
>>>>> Discussions
>>>>> will include endpoint security, mobile security and the latest in
>>>>> malware
>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Live Security Virtual Conference
>>> Exclusive live event will cover all the ways today's security and
>>> threat landscape has changed and how IT managers can respond. Discussions
>>> will include endpoint security, mobile security and the latest in malware
>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> _______________________________________________
>>> Csound-devel mailing list
>>> Csound-devel@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/csound-devel

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I'm looking forward to the Csound Journal. What can we expect this time?

On 8/2/12, Steven Yi  wrote:
> Hi All,
>
> I managed to get string args working (committed to GIT).  I added back
> in set_xincod and set_xoutcod but commented out the type checking
> parts that used the old otran global stuff, and left in the parts that
> set xincod for strings.  Strings now seem to be working as args to
> opcodes.
>
> Note:  I'll be taking a look at this off and on, but will likely not
> focus on this again until I get back to Ireland at the end of August.
> (Lot going on right now: new Csound Journal issue editing, moving,
> travels, presentations, etc.)
>
> I think next steps are to merge the latest changes from master to
> typesystem branch so it doesn't stray too far, then move forward with
> some bigger changes, namely the modifications for ksmps so that the
> hack used in calling UDO's can be removed.  Also, t-sigs currently are
> not added back in, as my plan to implement arrays generically so that
> arrays of any types could be created.
>
> Thanks!
> steven
>
>
> On Wed, Aug 1, 2012 at 7:35 PM, Steven Yi  wrote:
>> Update: I've managed to fix up the issue with memblock calculations by
>> adding a recalculateVarPoolMemory function that is called after ksmps
>> is set in CSOUND (pushed to GIT).  I'm working on handling string args
>> (having to reinstate set_xincod and set_xoutcod).  I see an issue with
>> memblock calculations for ksmps and UDO's, in that UDO's can have
>> setksmps. I think this might be an opportunity to finally remove the
>> ksmps hack for UDO's where it modifies the CSOUND*.  I'm not sure yet
>> what's the way forward with that, but regardless it will require an
>> overhaul of opcodes to lookup ksmps not from CSOUND itself but rather
>> from a CONTEXT struct or somewhere else that is set on the OPDS.
>>
>> Thanks,
>> steven
>>
>> On Wed, Aug 1, 2012 at 9:42 AM, Steven Yi  wrote:
>>> Hi John,
>>>
>>> The changes are in a branch called typesystem.  If you don't have the
>>> branch locally, you should be able to set it up by calling:
>>>
>>> git checkout -t origin/typesystem
>>>
>>> After that, you can switch between master and typesystem by just:
>>>
>>> git checkout master
>>> git checkout typesystem
>>>
>>> Note, there's still some things to do.  One aspect of these changes is
>>> to make csound more amenable to dynamic loading.  For example, moving
>>> labels to be just local to an instrument instead of being held in
>>> CSOUND* so that data doesn't hang around if an instrument is deleted.
>>> Also introducing a rule for a full semantic check pass before doing
>>> compiling to INSTRTXT prevent destructive edits to CSOUND state (no
>>> need to compile a new instrument and start modifying CSOUND if it's
>>> going to cause a type error). The current implementation also keeps
>>> around variable names, so if new instruments are going to be loaded
>>> during a run, they can lookup the mem addresses of global vars.
>>>
>>> Also for modification of an instrument it should be easier due to
>>> variables being tracked in a pool, meaning we could add new variables
>>> of any type to the pool and realloc the memory allocated for the
>>> instances.
>>>
>>> However, oload and insprep still has code that assumes no
>>> modifications during a run, such as allocating the global memory pool
>>> and other pools.  Those will need to be moved to another location or
>>> be done only if the pool pointers are NULL to start.
>>>
>>> Thanks!
>>> steven
>>>
>>> On Wed, Aug 1, 2012 at 6:08 AM,   wrote:
>>>> Where is the code?  I am not seeing it in git.  I was hoping to work on
>>>> loadable instruments v=but I suspect this overlaps what you are dong
>>>> ==John
>>>>
>>>>> Yes, things are going nicely!
>>>>>
>>>>> Another update: I've gotten labels and PFields now working.  I've
>>>>> changed label lookup in instance to use the recorded label name in the
>>>>> ARG* and search through the opcode chain for the corresponding LABEL
>>>>> opcode with the opnam of the label.  I imagine it's a bit slower than
>>>>> the previous implementation; certainly this can be optimized.  Also,
>>>>> the space allocated for bools was fixed to a size of MYFLT instead of
>>>>> int.  (Latest pushed to SourceForge.)
>>>>>
>>>>> I'm seeing one issue now with the design in that memblock sizes for
>>>>> variables is being calculated too early, before CSOUND* has been
>>>>> updated with the values from the CSD.  Consequently, currently a-var's
>>>>> are reporting memblock size of 10 * sizeof(MYFLT).  I'm going to work
>>>>> on fixing that up tomorrow.  I still need to work out string pool
>>>>> stuff as well, but all coming along.
>>>>>
>>>>> Thanks!
>>>>> steven
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jul 31, 2012 at 5:55 AM, Victor Lazzarini
>>>>>  wrote:
>>>>>> Sounds good, it really looks like good progress there.
>>>>>>
>>>>>> Victor
>>>>>> On 30 Jul 2012, at 22:59, Steven Yi wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Just another status update: I have replaced the use of variable
>>>>>>> counts
>>>>>>> with CS_VARIABLE's and VAR_POOL.  This involved also changing how
>>>>>>> arg
>>>>>>> indexes were handled (I am using a new ARG* struct that contains a
>>>>>>> reference to a CS_VAR or an index).  Doing this also removed the
>>>>>>> magic
>>>>>>> number work for args (i.e. positive is global, negative is local,
>>>>>>> but
>>>>>>> if > than some limit it's a string, etc.).  I had somewhat of a
>>>>>>> breakthrough just now in that I was able to run a simple CSD.
>>>>>>>
>>>>>>> I have to fix usage of labels (will be changing how labels are
>>>>>>> stored
>>>>>>> globally in CSOUND* and moving that to INSTRTXT), as well rework
>>>>>>> string constants (mostly done, just need to sense and hookup in
>>>>>>> memory
>>>>>>> in the STRING_POOL).  Understanding and modifying
>>>>>>> instance/otran/insprep took quite a while, but I think I've got a
>>>>>>> handle on it now and am moving forward.
>>>>>>>
>>>>>>> If curious, I've pushed my latest code changes to the csound6
>>>>>>> typesystem branch. It is very untidy at the moment, as there is a
>>>>>>> lot
>>>>>>> of commented out code and FIXME reminders for myself.  Those will be
>>>>>>> cleaned up by the time this is complete.
>>>>>>>
>>>>>>> Will update as things continue, thanks!
>>>>>>> steven
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Live Security Virtual Conference
>>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>>> threat landscape has changed and how IT managers can respond.
>>>>>>> Discussions
>>>>>>> will include endpoint security, mobile security and the latest in
>>>>>>> malware
>>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>> Dr Victor Lazzarini
>>>>>> Senior Lecturer
>>>>>> Dept. of Music
>>>>>> NUI Maynooth Ireland
>>>>>> tel.: +353 1 708 3545
>>>>>> Victor dot Lazzarini AT nuim dot ie
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Live Security Virtual Conference
>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>> threat landscape has changed and how IT managers can respond.
>>>>>> Discussions
>>>>>> will include endpoint security, mobile security and the latest in
>>>>>> malware
>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Live Security Virtual Conference
>>>>> Exclusive live event will cover all the ways today's security and
>>>>> threat landscape has changed and how IT managers can respond.
>>>>> Discussions
>>>>> will include endpoint security, mobile security and the latest in
>>>>> malware
>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond.
>>>> Discussions
>>>> will include endpoint security, mobile security and the latest in
>>>> malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

this string support will be so extremely useful!
thanks for your work on this, looking forward to use it -
	joachim


Am 02.08.2012 23:46, schrieb Steven Yi:
> Hi All,
>
> I managed to get string args working (committed to GIT).  I added back
> in set_xincod and set_xoutcod but commented out the type checking
> parts that used the old otran global stuff, and left in the parts that
> set xincod for strings.  Strings now seem to be working as args to
> opcodes.
>
> Note:  I'll be taking a look at this off and on, but will likely not
> focus on this again until I get back to Ireland at the end of August.
> (Lot going on right now: new Csound Journal issue editing, moving,
> travels, presentations, etc.)
>
> I think next steps are to merge the latest changes from master to
> typesystem branch so it doesn't stray too far, then move forward with
> some bigger changes, namely the modifications for ksmps so that the
> hack used in calling UDO's can be removed.  Also, t-sigs currently are
> not added back in, as my plan to implement arrays generically so that
> arrays of any types could be created.
>
> Thanks!
> steven
>
>
> On Wed, Aug 1, 2012 at 7:35 PM, Steven Yi  wrote:
>> Update: I've managed to fix up the issue with memblock calculations by
>> adding a recalculateVarPoolMemory function that is called after ksmps
>> is set in CSOUND (pushed to GIT).  I'm working on handling string args
>> (having to reinstate set_xincod and set_xoutcod).  I see an issue with
>> memblock calculations for ksmps and UDO's, in that UDO's can have
>> setksmps. I think this might be an opportunity to finally remove the
>> ksmps hack for UDO's where it modifies the CSOUND*.  I'm not sure yet
>> what's the way forward with that, but regardless it will require an
>> overhaul of opcodes to lookup ksmps not from CSOUND itself but rather
>> from a CONTEXT struct or somewhere else that is set on the OPDS.
>>
>> Thanks,
>> steven
>>
>> On Wed, Aug 1, 2012 at 9:42 AM, Steven Yi  wrote:
>>> Hi John,
>>>
>>> The changes are in a branch called typesystem.  If you don't have the
>>> branch locally, you should be able to set it up by calling:
>>>
>>> git checkout -t origin/typesystem
>>>
>>> After that, you can switch between master and typesystem by just:
>>>
>>> git checkout master
>>> git checkout typesystem
>>>
>>> Note, there's still some things to do.  One aspect of these changes is
>>> to make csound more amenable to dynamic loading.  For example, moving
>>> labels to be just local to an instrument instead of being held in
>>> CSOUND* so that data doesn't hang around if an instrument is deleted.
>>> Also introducing a rule for a full semantic check pass before doing
>>> compiling to INSTRTXT prevent destructive edits to CSOUND state (no
>>> need to compile a new instrument and start modifying CSOUND if it's
>>> going to cause a type error). The current implementation also keeps
>>> around variable names, so if new instruments are going to be loaded
>>> during a run, they can lookup the mem addresses of global vars.
>>>
>>> Also for modification of an instrument it should be easier due to
>>> variables being tracked in a pool, meaning we could add new variables
>>> of any type to the pool and realloc the memory allocated for the
>>> instances.
>>>
>>> However, oload and insprep still has code that assumes no
>>> modifications during a run, such as allocating the global memory pool
>>> and other pools.  Those will need to be moved to another location or
>>> be done only if the pool pointers are NULL to start.
>>>
>>> Thanks!
>>> steven
>>>
>>> On Wed, Aug 1, 2012 at 6:08 AM,   wrote:
>>>> Where is the code?  I am not seeing it in git.  I was hoping to work on
>>>> loadable instruments v=but I suspect this overlaps what you are dong
>>>> ==John
>>>>
>>>>> Yes, things are going nicely!
>>>>>
>>>>> Another update: I've gotten labels and PFields now working.  I've
>>>>> changed label lookup in instance to use the recorded label name in the
>>>>> ARG* and search through the opcode chain for the corresponding LABEL
>>>>> opcode with the opnam of the label.  I imagine it's a bit slower than
>>>>> the previous implementation; certainly this can be optimized.  Also,
>>>>> the space allocated for bools was fixed to a size of MYFLT instead of
>>>>> int.  (Latest pushed to SourceForge.)
>>>>>
>>>>> I'm seeing one issue now with the design in that memblock sizes for
>>>>> variables is being calculated too early, before CSOUND* has been
>>>>> updated with the values from the CSD.  Consequently, currently a-var's
>>>>> are reporting memblock size of 10 * sizeof(MYFLT).  I'm going to work
>>>>> on fixing that up tomorrow.  I still need to work out string pool
>>>>> stuff as well, but all coming along.
>>>>>
>>>>> Thanks!
>>>>> steven
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Jul 31, 2012 at 5:55 AM, Victor Lazzarini
>>>>>  wrote:
>>>>>> Sounds good, it really looks like good progress there.
>>>>>>
>>>>>> Victor
>>>>>> On 30 Jul 2012, at 22:59, Steven Yi wrote:
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>> Just another status update: I have replaced the use of variable counts
>>>>>>> with CS_VARIABLE's and VAR_POOL.  This involved also changing how arg
>>>>>>> indexes were handled (I am using a new ARG* struct that contains a
>>>>>>> reference to a CS_VAR or an index).  Doing this also removed the magic
>>>>>>> number work for args (i.e. positive is global, negative is local, but
>>>>>>> if > than some limit it's a string, etc.).  I had somewhat of a
>>>>>>> breakthrough just now in that I was able to run a simple CSD.
>>>>>>>
>>>>>>> I have to fix usage of labels (will be changing how labels are stored
>>>>>>> globally in CSOUND* and moving that to INSTRTXT), as well rework
>>>>>>> string constants (mostly done, just need to sense and hookup in memory
>>>>>>> in the STRING_POOL).  Understanding and modifying
>>>>>>> instance/otran/insprep took quite a while, but I think I've got a
>>>>>>> handle on it now and am moving forward.
>>>>>>>
>>>>>>> If curious, I've pushed my latest code changes to the csound6
>>>>>>> typesystem branch. It is very untidy at the moment, as there is a lot
>>>>>>> of commented out code and FIXME reminders for myself.  Those will be
>>>>>>> cleaned up by the time this is complete.
>>>>>>>
>>>>>>> Will update as things continue, thanks!
>>>>>>> steven
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Live Security Virtual Conference
>>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>>> threat landscape has changed and how IT managers can respond.
>>>>>>> Discussions
>>>>>>> will include endpoint security, mobile security and the latest in
>>>>>>> malware
>>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>>> _______________________________________________
>>>>>>> Csound-devel mailing list
>>>>>>> Csound-devel@lists.sourceforge.net
>>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>>
>>>>>> Dr Victor Lazzarini
>>>>>> Senior Lecturer
>>>>>> Dept. of Music
>>>>>> NUI Maynooth Ireland
>>>>>> tel.: +353 1 708 3545
>>>>>> Victor dot Lazzarini AT nuim dot ie
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Live Security Virtual Conference
>>>>>> Exclusive live event will cover all the ways today's security and
>>>>>> threat landscape has changed and how IT managers can respond.
>>>>>> Discussions
>>>>>> will include endpoint security, mobile security and the latest in
>>>>>> malware
>>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>>> _______________________________________________
>>>>>> Csound-devel mailing list
>>>>>> Csound-devel@lists.sourceforge.net
>>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Live Security Virtual Conference
>>>>> Exclusive live event will cover all the ways today's security and
>>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>>> will include endpoint security, mobile security and the latest in malware
>>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>>> _______________________________________________
>>>>> Csound-devel mailing list
>>>>> Csound-devel@lists.sourceforge.net
>>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Live Security Virtual Conference
>>>> Exclusive live event will cover all the ways today's security and
>>>> threat landscape has changed and how IT managers can respond. Discussions
>>>> will include endpoint security, mobile security and the latest in malware
>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>>> _______________________________________________
>>>> Csound-devel mailing list
>>>> Csound-devel@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

I'm not entirely confident this is not OT, but: given the surprising 
number of Python libraries that appear to exist (ancient and modern) for 
MIDI programming (real-time as well as files), can anyone offer 
recommendations? Cross-platform support is good to have if possible. 
Another criterion is that it is simple enough to be used in school 
CS/music classes (Python is one of the "approved" languages for computer 
science in UK schools). I would have gone for something like pyPortMidi, 
but that seems not to have been updated since 2005 or so.

Richard Dobson

On 11/08/2012 02:25, Victor Lazzarini wrote:
> For MIDI, I have tried this one, which is very simple to use, and
> appears to be kept updated.
>
> http://www.pygame.org/docs/ref/midi.html
>

Thanks, that looks very promising, and fits other school-oriented CS 
needs too (i.e. it may be being used already) as it is game oriented.

Richard Dobson