Since you seem to have opinions on the development of Csound, I would 
greatly appreciate hearing them more completely. What do you dislike, what 
do you like, and what would you like tos see added to Csound?

Reply privately if you like.

Best,
Mike

----- Original Message ----- 
From: "John Lato" 
To: 
Sent: Thursday, April 17, 2008 7:17 PM
Subject: [Csnd] Re: Re: Re: Re: Parallel hosts (was Re: Best hardware for 
Csound?)


> Although I have nothing against making it possible for csounders to 
> control threading through opcodes, I don't like the idea of it being 
> required in order to make use of multiple processors.  With the variety of 
> different types of inter-instrument communication, I think it would make 
> more sense to develop a parallelization system that would work in most 
> (all?) situations, with minimal effort on the part of the csound user.
>
> In fact, I do wish for a clean design of a new SWSS, which has led me to 
> look at Supercollider, ChucK, and other systems.  What keeps me coming 
> back to csound is the huge variety of (often very sophisticated) 
> processing available, which is far greater than most other systems.  Even 
> so, there are certain aspects of csound development I disagree with.  As 
> I'm not a csound developer, and I don't have time to devote to the effort, 
> I've kept my mouth shut.  Since I've already spoken up, though, I'll speak 
> plainly.  This approach strikes me as a very poor parallelization model 
> (for multiple reasons), and I don't want to see it added to csound and 
> then have further development hobbled by the need to continually support a 
> (IMO) poor decision.  I don't mean this as a disparagement to the 
> developers, who continue to do good work and accomplish some amazing 
> improvements in csound.  I just think that, in a situation where features 
> are never rescinded, a little more care should be taken before 
> implementing far-reaching changes.
>
> Cheers,
> John
>
> John W. Lato
> Sarah and Ernest Butler School of Music
> The University of Texas at Austin
> 1 University Station E3100
> Austin, TX 78712-0435
> (512) 232-2090
>
> Michael Gogins wrote:
>> This design can still be salvaged by providing methods for instances to 
>> communicate in a thread safe way. These could either be new opcodes, or 
>> thread-safety features in existing opcodes.
>>
>> The same logic that leads you to plead for a new "engine" leads one to 
>> wish for a clean design of a new software synthesis system, instead of 
>> continuing to wrestle with Csound.
>>
>> Like an idiot, I am both pursing a clean design of a new SWSS, AND 
>> continuing to wrestle with Csound.
>>
>> Regards,
>> Mike
>>
>> ----- Original Message ----- From: "John Lato" 
>> To: 
>> Sent: Thursday, April 17, 2008 6:09 PM
>> Subject: [Csnd] Re: Re: Parallel hosts (was Re: Best hardware for 
>> Csound?)
>>
>>
>>> I don't like this idea.  It will work as long as the instruments don't 
>>> talk to each other, or modify global global structures such as f-tables 
>>> (or some number of other conditions).  However, I expect that a large 
>>> number of orcs do one or more of those, and that complicated orchestras 
>>> (and real-time pieces) for which multicore capabilities would be most 
>>> useful are more likely to have complex inter-instrument communication, 
>>> or modify f-tables, etc.  Properly handling those situations would 
>>> require dealing with the issues that Steven mentioned.
>>>
>>> In short, even though I doubt this would take more than an afternoon for 
>>> someone familiar with the csound internals to implement, I would prefer 
>>> that developer time be spent actually working on a viable parallel 
>>> engine rather than this.
>>>
>>> John W. Lato
>>> Sarah and Ernest Butler School of Music
>>> The University of Texas at Austin
>>> 1 University Station E3100
>>> Austin, TX 78712-0435
>>> (512) 232-2090
>>>
>>> Michael Gogins wrote:
>>>> I agree, this is the way to go at this time.
>>>>
>>>> N instances of Csound created. Each starts and compiles the same 
>>>> orchestra.
>>>>
>>>> Just read a score file and send each line to 1 of the instances in 
>>>> turn, round-robin.
>>>>
>>>> Each instance runs in its own thread. When each thread has finished 
>>>> computing its buffer it waits, the buffers are summed into a real 
>>>> output buffer, when all threads are waiting the real output buffer is 
>>>> written to the real output, and the threads are signaled to resume.
>>>>
>>>> This is all fine as long as instruments in different instances don't 
>>>> talk to each other.
>>>>
>>>> Regards,
>>>> Mike
>>>>
>>>> -----Original Message-----
>>>>> From: victor 
>>>>> Sent: Apr 17, 2008 3:33 PM
>>>>> To: csound@lists.bath.ac.uk
>>>>> Subject: [Csnd] Parallel hosts (was Re: Best hardware for Csound?)
>>>>>
>>>>> yes, but that doesn't stop a parallel processing
>>>>> host being built, whereby two or more instances are
>>>>> run side by side.
>>>>> I think this might be a good way of going about it.
>>>>>
>>>>> Eventually a parser could be built that looks at a
>>>>> CSD and splits it into two or more running
>>>>> instances.
>>>>>
>>>>> Because Csound is reentrant, this is perfectly
>>>>> feasible. Also because we can go down to
>>>>> a ksmos level of granularity, this might not
>>>>> perform too badly.
>>>>>
>>>>> Victor
>>>>>
>>>>> ----- Original Message ----- From: "Steven Yi" 
>>>>> To: 
>>>>> Sent: Thursday, April 17, 2008 7:37 PM
>>>>> Subject: [Csnd] Re: Re: Re: Re: Re: Re: Best hardware for Csound?
>>>>>
>>>>>
>>>>>> I've thought about multicore quite a bit and csound internally can 
>>>>>> not
>>>>>> handle it at this time.  I did commit a naive implementation a year 
>>>>>> or
>>>>>> so ago.  The problem is that there are certain things that are not
>>>>>> safe, particularly things like the global currevt (I think that's the
>>>>>> name) pointing to the to current instrument instance being run that 
>>>>>> is
>>>>>> used by things like goto's to walk the chain of opcodes to find
>>>>>> labels.  I mentioned a while back about changing the instrument
>>>>>> building from single linked list to double linked list so that a goto
>>>>>> could search out from itself to find labels.  There are other things
>>>>>> that would need to be done such as introducing mutexes or semaphores
>>>>>> to protect access to global data like ftables, though much of that 
>>>>>> may
>>>>>> require user coding in csound to define where to do mutex
>>>>>> locks/unlocks.  (There are mutex opcodes I wrote that are in csound
>>>>>> but undocumented so that users can do the mutex locks/unlocks in 
>>>>>> their
>>>>>> csound code).
>>>>>>
>>>>>> Either way, the internals of Csound can not handle multicore at this
>>>>>> time.  If anyone wants to take a stab at it, I've thought about it a
>>>>>> number of times and have some ideas as to what needs to change so
>>>>>> might be able to help out there.
>>>>>>
>>>>>> steven
>>>
>>>
>>> Send bugs reports to this list.
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
>>> csound"
>>
>>
>>
>> Send bugs reports to this list.
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
>> csound"
>
>
> Send bugs reports to this list.
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe 
> csound"