The author of Rubato is a pro level mathematician, and the programmers of 
the system were very good also (I have looked a bit at the interfaces in the 
design). It is very easy to extend the system -- similar to what I had in 
the Java Silence and currently in CsoundAC, where you can just derive a new 
plugin from a base class and it gets picked up by the system.

There are no examples for the Rubato system, which is frustrating, but there 
are papers and books about it, with examples and tutorials in text form, so 
that provides something of a starting point.

My impression is that the design of the Rubato system is cleaner and more 
mathematically sophisticated than any of the other systems. But I need to 
know more about Open Music, so I'll check that out.

As I get back into composing, I'm probably going to play around with several 
composing systems, partly to get ideas for CsoundAC, and partly to see if I 
should be using one or more of them.

Best,
Mike

----- Original Message ----- 
From: "Steven Yi" 
To: "Developer discussions" 
Sent: Thursday, May 29, 2008 11:48 PM
Subject: Re: [Cs-dev] Threading


> Hi Michael,
>
> I'm not a fan of mutexes and of course would prefer some kind of
> automatic solution, but the number of areas of "global" resources and
> protecting them are of such a number that even if we do want to
> automate them, it will take long enough such that using mutexes in the
> interim will be worth it.  I also do not think we can reasonably cover
> all cases to protect resources in an automatic way that wouldn't end
> up too finely grained and where we end up spending too much time
> locking/unlocking.  In the same way that we have to manually code
> mutex locking in things like C/C++, I see the same requirement in
> coding Csound instruments.
>
> As for Rubato, I remember you mentioning it to me a while back and I
> took a look but ultimately didn't find it quite right for me.  I've
> been reading "The OM Composer's Book, Volume 1" lately (OM = Open
> Music) that was put out by Ircam and have been finding myself more
> curious about CAC (Computer Aided Composition) in the context of OM.
> I haven't had too much time to think what would make an ideal system
> and how it would work within blue, though I don't think I'm too far
> off for what I want to do musically and what's in blue already with
> coding python and building GUI's if necessary.  Anyways, I am thinking
> there is more to think about in looking at OM and SymbolicComposer
> than there is in Rubato, but I am saying this only with surface
> knowledge of these systems.
>
> steven
>
>
> On Thu, May 29, 2008 at 5:55 PM, Michael Gogins  
> wrote:
>> Steven, thanks for your thoughts.
>>
>> Regarding global data, it may be possible to protect such data and use it
>> anyway from multiple threads, inside the Csound code, not requiring the 
>> user
>> to create mutexes using the opcodes.
>>
>> I know about two approaches: locks (mutexes) and lock-free programming. 
>> I'm
>> not yet sure which is best in this context, but sharing global data 
>> should
>> be practical even in a compute intensive application like Csound with up 
>> to
>> dozens of threads. Beyond that, a more radical redesign will be required 
>> (we
>> will see hundreds or even thousands of cores in 5 or 10 years...).
>>
>> I agree with your comments about partitioning. I have not looked at the 
>> code
>> in enough detail yet to see how difficult it would be to hoist the
>> partioning up out of kperf itself, but I will give it a glance.
>>
>> On a separate note, have you looked at this: http://www.rubato.org?
>>
>> Regards,
>> Mike
>>
>>
>>
>> ----- Original Message -----
>> From: "Steven Yi" 
>> To: "Michael Gogins" ; "Developer discussions"
>> 
>> Sent: Thursday, May 29, 2008 1:38 PM
>> Subject: Re: [Cs-dev] Threading
>>
>>
>>> Hi Michael,
>>>
>>> To run with multiple threads, use --num-threads=x  where x is the
>>> number of threads to use (probably start off with x = num cores and
>>> try out different values there).  Not setting --num-threads defaults
>>> to 1 and therefore defaults to using the old scheduler and kperf.  For
>>> the ORC, we do not currently have support for any goto's, including
>>> any if's.  At least, not without using the mutex opcodes
>>> (http://www.nabble.com/Mutlithreaded-Csound-to9823048.html#a9823048).
>>> The code for the mutex ops are in Opcodes/mutexops.c.  I think you
>>> just give a mutex number to lock on, and the mutex opcodes will create
>>> a mutex and lock and unlock on that mutex.  You should also be able to
>>> do multiple locks and unlocks.
>>>
>>> I would suggest for just testing purposes now for performance to try
>>> out with very simple orchestras.
>>>
>>> Besides the problems with ifs/gotos, we need to see what other code is
>>> referencing CURREVT and any other "global" variable that is held in
>>> the Csound struct.  If we are going to pursue this seriously, I think
>>> we should aim to remove fields from the Csound struct that are global
>>> like this and break API compatibility, or at minimum, disable locally
>>> and remove all references and reenable to check in with a comment that
>>> it no longer should be used, if we want to maintain API compatibility.
>>> I'm for breaking API compatibility in this regard as I wouldn't want
>>> anyone in the future to try to use these values, but don't see a
>>> problem to stick with compatibility for now.
>>>
>>> Also, the work partition is done on each kperf which was done to work
>>> with the data structure that events are currently stored in (a long
>>> linked-list, sorted by instr num).  I think we would get benefit to
>>> instead do the work partition when events are added to the work queue
>>> and to pre-separate the work into different queues.  That way kperf
>>> won't have to repartition every pass but instead just do the work.
>>>
>>> Otherwise, doing a CVS update now and will try it out here on WinXP!
>>> steven
>>>
>>>
>>> On Thu, May 29, 2008 at 10:17 AM, Michael Gogins 
>>> wrote:
>>>> Now that I have replaced Windows threading with Posix threads 
>>>> (pthreads)
>>>> in the Windows build of Csound, and a cursory test says it still works, 
>>>> I
>>>> have questions.
>>>>
>>>> How do I enable the multi-threading option when rendering with Csound?
>>>>
>>>> Is there anything special I have to do, or not do, in my orc file?
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>>
>>>>
>>>> -------------------------------------------------------------------------
>>>> This SF.net email is sponsored by: Microsoft
>>>> Defy all challenges. Microsoft(R) Visual Studio 2008.
>>>> 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 2008.
>>> 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 2008.
>> 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 2008.
> 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 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net