Hi All,

I was doing some testing tonight and thought I'd post a video of some
live coding with Csound 6:

http://www.youtube.com/watch?v=xQAesz-ViKk

To note, I put together the editor and got the Csound code done pretty
quickly (all tonight).  Also, while the demo is showing live coding, I
think it's important to note that the capabilities added to the Csound
API for CS6 are going to be useful for API users in general for
building dynamic Csound applications.

Enjoy! :)

steven

nice!

On Fri, Mar 15, 2013 at 9:14 AM, Steven Yi  wrote:
> Hi All,
>
> I was doing some testing tonight and thought I'd post a video of some
> live coding with Csound 6:
>
> http://www.youtube.com/watch?v=xQAesz-ViKk
>
> To note, I put together the editor and got the Csound code done pretty
> quickly (all tonight).  Also, while the demo is showing live coding, I
> think it's important to note that the capabilities added to the Csound
> API for CS6 are going to be useful for API users in general for
> building dynamic Csound applications.
>
> Enjoy! :)
>
> steven
>
>
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>



-- 
SaRiGaMa's Oil Vending Orchestra
is podcasting:
http://sarigama.namaste.jp/podcast/rss.xml

Hi Thorin,

I think it's implemented such that when a new instrument replaces an
old one, existing instances continue using the old instrument
definition.  New notes will use the new definition.  I remember
discussing with Victor and John what to do in this situation, and I
think the current implementation has a dead pool where replaced
instruments go.  That way existing notes can keep processing and do
release segments, and the old definition finally gets removed when all
existing notes are complete.

I'm not sure what happens if notes are currently held when the switch
happens, if they get signaled to turnoff and do release processing.
Perhaps Victor could clarify.

I'll put up a video of a more interesting live coding example in just
a bit that might show a little more of what's possible.

Thanks!
steven

On Fri, Mar 15, 2013 at 4:59 AM, thorin kerr  wrote:
> This looks very promising. I have a quick question Steven. Do you need to
> create a new 'i' score event to realise the changes? Or... can you have an
> 'always on' instrument which can be modified 'on the fly'?
>
> Thorin
>
>
>
>
>
> On Fri, Mar 15, 2013 at 10:14 AM, Steven Yi  wrote:
>>
>> Hi All,
>>
>> I was doing some testing tonight and thought I'd post a video of some
>> live coding with Csound 6:
>>
>> http://www.youtube.com/watch?v=xQAesz-ViKk
>>
>> To note, I put together the editor and got the Csound code done pretty
>> quickly (all tonight).  Also, while the demo is showing live coding, I
>> think it's important to note that the capabilities added to the Csound
>> API for CS6 are going to be useful for API users in general for
>> building dynamic Csound applications.
>>
>> Enjoy! :)
>>
>> steven
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>

That's pretty much what I recorded doing this morning. :-) The audio was breaking up unfortunately, I think due to not being plugged in (was on a train). I'll re-record later tonight and post on YouTube.

Thanks for the video, Steven! This looks quite promising. It also begins to
look a bit like programming in SuperCollider! One of the great strengths of
SC, though, is that there are so many stochastic note generation functions
built into the language. So you can easily generate numerous note events
algorithmically with just a few lines of code. In Csound, we either build
complex instruments to do this, or we use a front end to generate lots of
i-statements, but there really is nothing comparable to what SC offers - at
least, not in Csound's score functions. I think this severely limits what is
possible to do with live coding. I have long wished that something like
CMASK was integrated into the Csound score processor, because that would
open up so many possibilities. Just saying...

> -----Original Message-----
> From: Steven Yi [mailto:stevenyi@gmail.com]
> Sent: Thursday, March 14, 2013 7:15 PM
> To: Csound
> Subject: [Csnd] Csound 6 - Live Coding Demo
> 
> Hi All,
> 
> I was doing some testing tonight and thought I'd post a video of some
> live coding with Csound 6:
> 
> http://www.youtube.com/watch?v=xQAesz-ViKk
> 
> To note, I put together the editor and got the Csound code done pretty
> quickly (all tonight).  Also, while the demo is showing live coding, I
> think it's important to note that the capabilities added to the Csound
> API for CS6 are going to be useful for API users in general for
> building dynamic Csound applications.
> 
> Enjoy! :)
> 
> steven
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"

+1

i agree absolutely totaly !!!

stf

Le 15 mars 2013 à 16:14, Russell Pinkston  a écrit :

> Thanks for the video, Steven! This looks quite promising. It also begins to
> look a bit like programming in SuperCollider! One of the great strengths of
> SC, though, is that there are so many stochastic note generation functions
> built into the language. So you can easily generate numerous note events
> algorithmically with just a few lines of code. In Csound, we either build
> complex instruments to do this, or we use a front end to generate lots of
> i-statements, but there really is nothing comparable to what SC offers - at
> least, not in Csound's score functions. I think this severely limits what is
> possible to do with live coding. I have long wished that something like
> CMASK was integrated into the Csound score processor, because that would
> open up so many possibilities. Just saying...
> 
>> -----Original Message-----
>> From: Steven Yi [mailto:stevenyi@gmail.com]
>> Sent: Thursday, March 14, 2013 7:15 PM
>> To: Csound
>> Subject: [Csnd] Csound 6 - Live Coding Demo
>> 
>> Hi All,
>> 
>> I was doing some testing tonight and thought I'd post a video of some
>> live coding with Csound 6:
>> 
>> http://www.youtube.com/watch?v=xQAesz-ViKk
>> 
>> To note, I put together the editor and got the Csound code done pretty
>> quickly (all tonight).  Also, while the demo is showing live coding, I
>> think it's important to note that the capabilities added to the Csound
>> API for CS6 are going to be useful for API users in general for
>> building dynamic Csound applications.
>> 
>> Enjoy! :)
>> 
>> steven
>> 
>> 
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
> 
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 

Hi Russell,

Thanks! In some ways I agree regarding SC and note generators, but on the other hand, I think it would not be too difficult to do with Csound too. The video I had recorded earlier had used arrays to store pitches, and I was varying the lengths of times either manually or with random jitter added. I'll see about demoing cycling and single shots through patterns of notes, as well as some random shuffling for the video tonight.

What I expect is that the code will be cleaner than expected, but could be also be easier still once we sort out passing arrays to UDO's.

Thanks!
Steven

Hopefully we can add a suite of SC-based opcodes
- to both the .orc and .sco 

or 

a SC-inspired UDO collection.

-dB

On Mar 15, 2013, at 11:14 AM, Russell Pinkston  wrote:

> Thanks for the video, Steven! This looks quite promising. It also begins to
> look a bit like programming in SuperCollider! One of the great strengths of
> SC, though, is that there are so many stochastic note generation functions
> built into the language. So you can easily generate numerous note events
> algorithmically with just a few lines of code. In Csound, we either build
> complex instruments to do this, or we use a front end to generate lots of
> i-statements, but there really is nothing comparable to what SC offers - at
> least, not in Csound's score functions. I think this severely limits what is
> possible to do with live coding. I have long wished that something like
> CMASK was integrated into the Csound score processor, because that would
> open up so many possibilities. Just saying...
> 
>> -----Original Message-----
>> From: Steven Yi [mailto:stevenyi@gmail.com]
>> Sent: Thursday, March 14, 2013 7:15 PM
>> To: Csound
>> Subject: [Csnd] Csound 6 - Live Coding Demo
>> 
>> Hi All,
>> 
>> I was doing some testing tonight and thought I'd post a video of some
>> live coding with Csound 6:
>> 
>> http://www.youtube.com/watch?v=xQAesz-ViKk
>> 
>> To note, I put together the editor and got the Csound code done pretty
>> quickly (all tonight).  Also, while the demo is showing live coding, I
>> think it's important to note that the capabilities added to the Csound
>> API for CS6 are going to be useful for API users in general for
>> building dynamic Csound applications.
>> 
>> Enjoy! :)
>> 
>> steven
>> 
>> 
>> Send bugs reports to the Sourceforge bug tracker
>>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
> 
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
> 

Keep the videos coming please!

On 15 March 2013 15:35, Steven Yi  wrote:
> Hi Russell,
>
> Thanks! In some ways I agree regarding SC and note generators, but on the
> other hand, I think it would not be too difficult to do with Csound too. The
> video I had recorded earlier had used arrays to store pitches, and I was
> varying the lengths of times either manually or with random jitter added.
> I'll see about demoing cycling and single shots through patterns of notes,
> as well as some random shuffling for the video tonight.
>
> What I expect is that the code will be cleaner than expected, but could be
> also be easier still once we sort out passing arrays to UDO's.
>
> Thanks!
> Steven
>
> On Mar 15, 2013 3:15 PM, "Russell Pinkston" 
> wrote:
>>
>> Thanks for the video, Steven! This looks quite promising. It also begins
>> to
>> look a bit like programming in SuperCollider! One of the great strengths
>> of
>> SC, though, is that there are so many stochastic note generation functions
>> built into the language. So you can easily generate numerous note events
>> algorithmically with just a few lines of code. In Csound, we either build
>> complex instruments to do this, or we use a front end to generate lots of
>> i-statements, but there really is nothing comparable to what SC offers -
>> at
>> least, not in Csound's score functions. I think this severely limits what
>> is
>> possible to do with live coding. I have long wished that something like
>> CMASK was integrated into the Csound score processor, because that would
>> open up so many possibilities. Just saying...
>>
>> > -----Original Message-----
>> > From: Steven Yi [mailto:stevenyi@gmail.com]
>> > Sent: Thursday, March 14, 2013 7:15 PM
>> > To: Csound
>> > Subject: [Csnd] Csound 6 - Live Coding Demo
>> >
>> > Hi All,
>> >
>> > I was doing some testing tonight and thought I'd post a video of some
>> > live coding with Csound 6:
>> >
>> > http://www.youtube.com/watch?v=xQAesz-ViKk
>> >
>> > To note, I put together the editor and got the Csound code done pretty
>> > quickly (all tonight).  Also, while the demo is showing live coding, I
>> > think it's important to note that the capabilities added to the Csound
>> > API for CS6 are going to be useful for API users in general for
>> > building dynamic Csound applications.
>> >
>> > Enjoy! :)
>> >
>> > steven
>> >
>> >
>> > Send bugs reports to the Sourceforge bug tracker
>> >             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> > Discussions of bugs and features can be posted here
>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> > csound"
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>

In some ways, SC has adhered pretty closely to the original MusicN paradigm,
with its separation of sound generation and note specification into separate
tasks. In SC, all sound generation takes place on the server, while note
generation happens on the language side. To some extent, I think the later
versions of Csound have moved away from this paradigm, with more and more
event generation capabilities being added to the orchestra, but with
comparatively few enhancements to the note generation capabilities of the
score processor. To some extent, historically, this is probably due to the
advent of real time, MIDI controlled and/or VST-capable orchestras, which
essentially bypass the score altogether. It's also undoubtedly due to the
existence of score generators like CMASK, front ends like Cecelia and Blue,
and more recently, the Python interface. Whatever the causes, though, I
think it's obvious that there has been an ever-increasing focus on adding
functionality to the orchestra. Perhaps the next great frontier for Csound
development lies in the humble score.

> -----Original Message-----
> From: Richard Boulanger [mailto:rboulanger@berklee.edu]
> Sent: Friday, March 15, 2013 10:55 AM
> To: csound@lists.bath.ac.uk
> Subject: Re: [Csnd] Csound 6 - Live Coding Demo
> 
> Hopefully we can add a suite of SC-based opcodes
> - to both the .orc and .sco
> 
> or
> 
> a SC-inspired UDO collection.
> 
> -dB
> 
> On Mar 15, 2013, at 11:14 AM, Russell Pinkston
>  wrote:
> 
> > Thanks for the video, Steven! This looks quite promising. It also begins
> to
> > look a bit like programming in SuperCollider! One of the great strengths
> of
> > SC, though, is that there are so many stochastic note generation
> functions
> > built into the language. So you can easily generate numerous note events
> > algorithmically with just a few lines of code. In Csound, we either
> build
> > complex instruments to do this, or we use a front end to generate lots
> of
> > i-statements, but there really is nothing comparable to what SC offers -
> at
> > least, not in Csound's score functions. I think this severely limits
> what is
> > possible to do with live coding. I have long wished that something like
> > CMASK was integrated into the Csound score processor, because that would
> > open up so many possibilities. Just saying...
> >
> >> -----Original Message-----
> >> From: Steven Yi [mailto:stevenyi@gmail.com]
> >> Sent: Thursday, March 14, 2013 7:15 PM
> >> To: Csound
> >> Subject: [Csnd] Csound 6 - Live Coding Demo
> >>
> >> Hi All,
> >>
> >> I was doing some testing tonight and thought I'd post a video of some
> >> live coding with Csound 6:
> >>
> >> http://www.youtube.com/watch?v=xQAesz-ViKk
> >>
> >> To note, I put together the editor and got the Csound code done pretty
> >> quickly (all tonight).  Also, while the demo is showing live coding, I
> >> think it's important to note that the capabilities added to the Csound
> >> API for CS6 are going to be useful for API users in general for
> >> building dynamic Csound applications.
> >>
> >> Enjoy! :)
> >>
> >> steven
> >>
> >>
> >> Send bugs reports to the Sourceforge bug tracker
> >>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> >> Discussions of bugs and features can be posted here
> >> To unsubscribe, send email sympa@lists.bath.ac.uk with body
> "unsubscribe
> >> csound"
> >
> >
> >
> > Send bugs reports to the Sourceforge bug tracker
> >            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> > Discussions of bugs and features can be posted here
> > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
> >
> 
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
> 
> =

but isn't the generation of instrument events in the orc much more 
flexible? do you have an example for the preferability of a score generator?

	joachim


Am 15.03.2013 18:05, schrieb Russell Pinkston:
> In some ways, SC has adhered pretty closely to the original MusicN paradigm,
> with its separation of sound generation and note specification into separate
> tasks. In SC, all sound generation takes place on the server, while note
> generation happens on the language side. To some extent, I think the later
> versions of Csound have moved away from this paradigm, with more and more
> event generation capabilities being added to the orchestra, but with
> comparatively few enhancements to the note generation capabilities of the
> score processor. To some extent, historically, this is probably due to the
> advent of real time, MIDI controlled and/or VST-capable orchestras, which
> essentially bypass the score altogether. It's also undoubtedly due to the
> existence of score generators like CMASK, front ends like Cecelia and Blue,
> and more recently, the Python interface. Whatever the causes, though, I
> think it's obvious that there has been an ever-increasing focus on adding
> functionality to the orchestra. Perhaps the next great frontier for Csound
> development lies in the humble score.
>
>> -----Original Message-----
>> From: Richard Boulanger [mailto:rboulanger@berklee.edu]
>> Sent: Friday, March 15, 2013 10:55 AM
>> To: csound@lists.bath.ac.uk
>> Subject: Re: [Csnd] Csound 6 - Live Coding Demo
>>
>> Hopefully we can add a suite of SC-based opcodes
>> - to both the .orc and .sco
>>
>> or
>>
>> a SC-inspired UDO collection.
>>
>> -dB
>>
>> On Mar 15, 2013, at 11:14 AM, Russell Pinkston
>>  wrote:
>>
>>> Thanks for the video, Steven! This looks quite promising. It also begins
>> to
>>> look a bit like programming in SuperCollider! One of the great strengths
>> of
>>> SC, though, is that there are so many stochastic note generation
>> functions
>>> built into the language. So you can easily generate numerous note events
>>> algorithmically with just a few lines of code. In Csound, we either
>> build
>>> complex instruments to do this, or we use a front end to generate lots
>> of
>>> i-statements, but there really is nothing comparable to what SC offers -
>> at
>>> least, not in Csound's score functions. I think this severely limits
>> what is
>>> possible to do with live coding. I have long wished that something like
>>> CMASK was integrated into the Csound score processor, because that would
>>> open up so many possibilities. Just saying...
>>>
>>>> -----Original Message-----
>>>> From: Steven Yi [mailto:stevenyi@gmail.com]
>>>> Sent: Thursday, March 14, 2013 7:15 PM
>>>> To: Csound
>>>> Subject: [Csnd] Csound 6 - Live Coding Demo
>>>>
>>>> Hi All,
>>>>
>>>> I was doing some testing tonight and thought I'd post a video of some
>>>> live coding with Csound 6:
>>>>
>>>> http://www.youtube.com/watch?v=xQAesz-ViKk
>>>>
>>>> To note, I put together the editor and got the Csound code done pretty
>>>> quickly (all tonight).  Also, while the demo is showing live coding, I
>>>> think it's important to note that the capabilities added to the Csound
>>>> API for CS6 are going to be useful for API users in general for
>>>> building dynamic Csound applications.
>>>>
>>>> Enjoy! :)
>>>>
>>>> steven
>>>>
>>>>
>>>> Send bugs reports to the Sourceforge bug tracker
>>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>>> Discussions of bugs and features can be posted here
>>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> "unsubscribe
>>>> csound"
>>>
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>>
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>              https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>> =
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>              https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>

I always saw the score not as something to be augmented, but as
something to be helped along, so to speak. You don't put wheels on a
person to make her roll (unless she's some form of Mulefa) but you
give her a car (and a driver's license :-)).

On 3/15/13, Russell Pinkston  wrote:
> In some ways, SC has adhered pretty closely to the original MusicN
> paradigm,
> with its separation of sound generation and note specification into
> separate
> tasks. In SC, all sound generation takes place on the server, while note
> generation happens on the language side. To some extent, I think the later
> versions of Csound have moved away from this paradigm, with more and more
> event generation capabilities being added to the orchestra, but with
> comparatively few enhancements to the note generation capabilities of the
> score processor. To some extent, historically, this is probably due to the
> advent of real time, MIDI controlled and/or VST-capable orchestras, which
> essentially bypass the score altogether. It's also undoubtedly due to the
> existence of score generators like CMASK, front ends like Cecelia and Blue,
> and more recently, the Python interface. Whatever the causes, though, I
> think it's obvious that there has been an ever-increasing focus on adding
> functionality to the orchestra. Perhaps the next great frontier for Csound
> development lies in the humble score.
>
>> -----Original Message-----
>> From: Richard Boulanger [mailto:rboulanger@berklee.edu]
>> Sent: Friday, March 15, 2013 10:55 AM
>> To: csound@lists.bath.ac.uk
>> Subject: Re: [Csnd] Csound 6 - Live Coding Demo
>>
>> Hopefully we can add a suite of SC-based opcodes
>> - to both the .orc and .sco
>>
>> or
>>
>> a SC-inspired UDO collection.
>>
>> -dB
>>
>> On Mar 15, 2013, at 11:14 AM, Russell Pinkston
>>  wrote:
>>
>> > Thanks for the video, Steven! This looks quite promising. It also
>> > begins
>> to
>> > look a bit like programming in SuperCollider! One of the great
>> > strengths
>> of
>> > SC, though, is that there are so many stochastic note generation
>> functions
>> > built into the language. So you can easily generate numerous note
>> > events
>> > algorithmically with just a few lines of code. In Csound, we either
>> build
>> > complex instruments to do this, or we use a front end to generate lots
>> of
>> > i-statements, but there really is nothing comparable to what SC offers
>> > -
>> at
>> > least, not in Csound's score functions. I think this severely limits
>> what is
>> > possible to do with live coding. I have long wished that something like
>> > CMASK was integrated into the Csound score processor, because that
>> > would
>> > open up so many possibilities. Just saying...
>> >
>> >> -----Original Message-----
>> >> From: Steven Yi [mailto:stevenyi@gmail.com]
>> >> Sent: Thursday, March 14, 2013 7:15 PM
>> >> To: Csound
>> >> Subject: [Csnd] Csound 6 - Live Coding Demo
>> >>
>> >> Hi All,
>> >>
>> >> I was doing some testing tonight and thought I'd post a video of some
>> >> live coding with Csound 6:
>> >>
>> >> http://www.youtube.com/watch?v=xQAesz-ViKk
>> >>
>> >> To note, I put together the editor and got the Csound code done pretty
>> >> quickly (all tonight).  Also, while the demo is showing live coding, I
>> >> think it's important to note that the capabilities added to the Csound
>> >> API for CS6 are going to be useful for API users in general for
>> >> building dynamic Csound applications.
>> >>
>> >> Enjoy! :)
>> >>
>> >> steven
>> >>
>> >>
>> >> Send bugs reports to the Sourceforge bug tracker
>> >>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >> Discussions of bugs and features can be posted here
>> >> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> "unsubscribe
>> >> csound"
>> >
>> >
>> >
>> > Send bugs reports to the Sourceforge bug tracker
>> >            https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> > Discussions of bugs and features can be posted here
>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> > "unsubscribe
>> csound"
>> >
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>> =
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>

thanks for explaining more in detail what you meant. i am wondering 
whether the problems are in a way in fact deriving from the seperation 
of orc language on one side from sco language on the other side. this 
separation has its historical reasons, and is still very practical and 
clear in many cases, but on the other hand it prevents a dynamic 
behaviour (to trigger events depending on what is happening in an 
instrument) and it tends to be strange to use another syntax in the sco 
than in the orc. (as a simple example we must explain the students that 
the 'i' in the scoreline i 1 0 1 has nothing to do with the 'i' in an 
instrument's i-rate variable name.)
i think the way for a better learning curve is
1. to implement standard data and control structures in the orc language 
(what steven, victor and john are doing right now), and
2. to find conventions for them which are as intuitive and simple as 
possible. i think it would be good to discuss these conventions in the 
community to hear opinions and to find the best possible solution (which 
is not easy). python is certainly a good model for understandable code.

	joachim


Am 15.03.2013 21:04, schrieb Russell Pinkston:
> All these options are great, and there’s no question that if you use
> Csound in conjunction with an external programming language (and you
> happen to know that language), the possibilities for score generation
> are virtually unlimited. But I would submit that they are all various
> work-arounds for the inherent deficiencies in the Csound score
> processor. Speaking as a teacher who works primarily with musicians and
> composers, rather than engineers and computer scientists, I find it very
> awkward that one has to teach people how to use a front end (let alone a
> general purpose programming language), in order to get interesting music
> out of Csound. It’s hard enough for a non-programmer to learn how to use
> Csound, itself, without also having to learn Python at the same time.
> Similarly, if you decide to teach Csound using a front end (like
> Cecilia, for example), it’s easy for your students to get confused about
> what is Csound and what is the front end. And I also find that they tend
> to become overly reliant on the front end, because it’s so easy to get
> cool results without really knowing what they are doing. I think this is
> where Max/MSP has a great advantage over Csound, because a) the
> interface is so intuitive, b) it is self-contained (you don’t need to
> know another language to get interesting results), and c) everything
> works more or less the same way, whether it is synthesis, audio
> processing, graphics, or note generation. (It also helps that you don’t
> have to build your own GUIs!) The learning curve for Csound is far
> steeper, which is too bad, because it is so much more powerful, in terms
> of synthesis and audio processing.
>
> Joachim wrote:
>
> “but isn't the generation of instrument events in the orc much more
> flexible? do you have an example for the preferability of a score
> generator?”
>
> I would agree that, as things stand now, it is more flexible to generate
> events in the orchestra. I use event and schedkwhen all the time in my
> own work, and also in my classes, because they are pretty easy for
> students to understand. But I think that when we start using instruments
> to generate note events, we lose some of the clarity (and elegance) that
> the original MusicN languages had through their separation of synthesis
> (the orchestra) from note specification (the score). And how easy is it
> to implement something as basic as varying probability weights (trivial
> with CMASK), or a Markov Chain (easy with the prob function in Max), or
> even the equivalent of SC’s Pshuf, or the Max urn (unique random number
> generator) object? All of these things can be done in the Csound
> orchestra, too, as well as in Python, or Java, or c, of course. But I
> submit that Csound, itself, would be improved by having such things
> readily available as built-in score functions. One of the great things
> about Csound has always been that a simple ASCII text file could
> represent an entire piece of music – the ultimate form of data
> compression, as Barry Vercoe once said.
>
> ------------------------------------------------------------------------
>
> *From:*Michael Gogins [mailto:michael.gogins@gmail.com]
> *Sent:* Friday, March 15, 2013 1:32 PM
> *To:* Csound
> *Subject:* Re: [Csnd] Csound 6 - Live Coding Demo
>
> Thanks, that's (6). That also should permit both pre-generation of
> scores, and continued control of the running Csound from the score
> generator.
>
> Regards,
>
> Mike
>
> On Fri, Mar 15, 2013 at 1:53 PM, Justin Smith  > wrote:
>
> my most frequent method
>
> 6) run csound with -Lstdin via fork() or your language's equivalent, and
> hand it score events on standard input
>
> On Fri, Mar 15, 2013 at 10:44 AM, Michael Gogins
> > wrote:
>
> Many people use Csound with other languages, which are more highly
> developed and more powerful, for score generation. These can be as
> loosely or tightly bound to Csound itself as you like. I list the basic
> patterns below.
>
> I would like to stress that patterns (2) and (4) run Csound in the same
> address space as the score generator, and thus permit painless,
> efficient communication between Csound and the score generator, which
> can include a user interface. Both (2) and (4) permit the user to work
> in a single environment and to use widely known, very powerful, very
> fast programming languages to generate scores.
>
> One more thing before the list, in Csound code, there is a lot you can
> do in the orchestra header, before any instruments are defined or
> instantiated. So in patterns (2) and (4), and maybe (5), it is possible
> to generate an entire score of any complexity in the orchestra header
> before any sound begins. But it is also possible to set up threads or
> processes that continue to feed notes or control events into the
> performance.
>
> (1) Run your score generator and then shell out to run Csound (any
> language). In this case, one is limited to generating the score before
> Csound consumes it.
>
> (2) Run your score generator, and it embeds Csound via the Csound API
> (C, C++, Java, Python, Lua, Lisp). In this case, one can include control
> channels, feedback back and forth between Csound and score generator,
> etc. Some Csound front ends permit the use of Python coding, or other
> languages, during performance. NOTE: the front ends themselves are
> examples of this pattern.
>
> (3) Run Csound, and it shells out transparently to run your score
> generator (bin attribute in score element of csd file) (any language!).
> In this case, one is limited to generating the score before Csound
> consumes it.
>
> (4) Run Csound, and it embeds your score generator directly (Lua, using
> the Lua opcodes). In this case, one generates the score as Csound as
> running, and this can include control channels, feedback back and forth
> between Csound and score generator, etc.
>
> (5) Generate the score in Csound code. As the orchestra language gains a
> type system and arrays, this will become more and more powerful.
>
> Regards,
>
> Mike
>
> On Fri, Mar 15, 2013 at 1:05 PM, Russell Pinkston
> > wrote:
>
> In some ways, SC has adhered pretty closely to the original MusicN paradigm,
> with its separation of sound generation and note specification into separate
> tasks. In SC, all sound generation takes place on the server, while note
> generation happens on the language side. To some extent, I think the later
> versions of Csound have moved away from this paradigm, with more and more
> event generation capabilities being added to the orchestra, but with
> comparatively few enhancements to the note generation capabilities of the
> score processor. To some extent, historically, this is probably due to the
> advent of real time, MIDI controlled and/or VST-capable orchestras, which
> essentially bypass the score altogether. It's also undoubtedly due to the
> existence of score generators like CMASK, front ends like Cecelia and Blue,
> and more recently, the Python interface. Whatever the causes, though, I
> think it's obvious that there has been an ever-increasing focus on adding
> functionality to the orchestra. Perhaps the next great frontier for Csound
> development lies in the humble score.
>
>
>> -----Original Message-----
>> From: Richard Boulanger [mailto:rboulanger@berklee.edu ]
>> Sent: Friday, March 15, 2013 10:55 AM
>> To:csound@lists.bath.ac.uk 
>> Subject: Re: [Csnd] Csound 6 - Live Coding Demo
>>
>> Hopefully we can add a suite of SC-based opcodes
>> - to both the .orc and .sco
>>
>> or
>>
>> a SC-inspired UDO collection.
>>
>> -dB
>>
>> On Mar 15, 2013, at 11:14 AM, Russell Pinkston
>> > wrote:
>>
>> > Thanks for the video, Steven! This looks quite promising. It also  begins
>> to
>> > look a bit like programming in SuperCollider! One of the great  strengths
>> of
>> > SC, though, is that there are so many stochastic note generation
>> functions
>> > built into the language. So you can easily generate numerous note  events
>> > algorithmically with just a few lines of code. In Csound, we either
>> build
>> > complex instruments to do this, or we use a front end to generate  lots
>> of
>> > i-statements, but there really is nothing comparable to what SC offers  -
>> at
>> > least, not in Csound's score functions. I think this severely limits
>> what is
>> > possible to do with live coding. I have long wished that something  like
>> > CMASK was integrated into the Csound score processor, because that  would
>> > open up so many possibilities. Just saying...
>> >
>> >> -----Original Message-----
>> >> From: Steven Yi [mailto:stevenyi@gmail.com ]
>> >> Sent: Thursday, March 14, 2013 7:15 PM
>> >> To: Csound
>> >> Subject: [Csnd] Csound 6 - Live Coding Demo
>> >>
>> >> Hi All,
>> >>
>> >> I was doing some testing tonight and thought I'd post a video of  some
>> >> live coding with Csound 6:
>> >>
>> >>http://www.youtube.com/watch?v=xQAesz-ViKk
>> >>
>> >> To note, I put together the editor and got the Csound code done  pretty
>> >> quickly (all tonight).  Also, while the demo is showing live  coding, I
>> >> think it's important to note that the capabilities added to the  Csound
>> >> API for CS6 are going to be useful for API users in general for
>> >> building dynamic Csound applications.
>> >>
>> >> Enjoy! :)
>> >>
>> >> steven
>> >>
>> >>
>> >> Send bugs reports to the Sourceforge bug tracker
>> >>https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >> Discussions of bugs and features can be posted here
>> >> To unsubscribe, send emailsympa@lists.bath.ac.uk  with body
>> "unsubscribe
>> >> csound"
>> >
>> >
>> >
>> > Send bugs reports to the Sourceforge bug tracker
>> >https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> > Discussions of bugs and features can be posted here
>> > To unsubscribe, send emailsympa@lists.bath.ac.uk  with body
> "unsubscribe
>> csound"
>> >
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send emailsympa@lists.bath.ac.uk  with body
> "unsubscribe
>> csound"
>>
>> =
>
>
>
> Send bugs reports to the Sourceforge bug tracker
> https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk
>  with body "unsubscribe csound"
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>
>
>
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
>

on 2013-03-15 at 00:14 Steven Yi wrote:

>I was doing some testing tonight and thought I'd post a video of some
>live coding with Csound 6:

this is really great, steven, thanks for posting. makes me realize how far
behind the recent advances of csound i am...

this "csound editor" is an application you developed for OSX? could
something like this be achieved from a standard "power" editor like vim or
emacs?


best,


lj

If this is integrated into emacs I might even use live coding......

>
> on 2013-03-15 at 00:14 Steven Yi wrote:
>
>>I was doing some testing tonight and thought I'd post a video of some
>>live coding with Csound 6:
>
> this is really great, steven, thanks for posting. makes me realize how far
> behind the recent advances of csound i am...
>
> this "csound editor" is an application you developed for OSX? could
> something like this be achieved from a standard "power" editor like vim or
> emacs?
>
>
> best,
>
>
> lj
>
>
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>
>
>

Going back to a point Joachim made, now is probably the best time to
discuss such conventions and how they can be brought into the future
of the language as we move ever closer towards Csound 6. I love the
addition of the until loop and I can see already see how using arrays
will completely change the way I work with Csound. I still think a
more Csound like endloop keyword would make it more accessible. Are
stings arrays also possible?



On 15 March 2013 22:52,   wrote:
> If this is integrated into emacs I might even use live coding......
>
>>
>> on 2013-03-15 at 00:14 Steven Yi wrote:
>>
>>>I was doing some testing tonight and thought I'd post a video of some
>>>live coding with Csound 6:
>>
>> this is really great, steven, thanks for posting. makes me realize how far
>> behind the recent advances of csound i am...
>>
>> this "csound editor" is an application you developed for OSX? could
>> something like this be achieved from a standard "power" editor like vim or
>> emacs?
>>
>>
>> best,
>>
>>
>> lj
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
>>
>>
>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>

Hi Luis,

I put together the application in Java, using Netbeans' GUI designer
to setup the UI.  There isn't too much to it really, it's just using
the Csound API.  The run button either starts or stops Csound, and the
evaluate action uses csound.CompileOrc(text) or csound.ReadScore(text)
depending on which tab is selected.

Re: vim and emacs, I imagine it should be possible, though I haven't
done any extension writing for either so am not familiar enough to say
for sure.  I don't know how plugins are done that provide REPL
support, but I think whatever would be required for that would be what
would be necessary here.  I think it'd be great to see emacs and vim
support.

Thanks!
steven

On Fri, Mar 15, 2013 at 10:44 PM, luis jure  wrote:
>
> on 2013-03-15 at 00:14 Steven Yi wrote:
>
>>I was doing some testing tonight and thought I'd post a video of some
>>live coding with Csound 6:
>
> this is really great, steven, thanks for posting. makes me realize how far
> behind the recent advances of csound i am...
>
> this "csound editor" is an application you developed for OSX? could
> something like this be achieved from a standard "power" editor like vim or
> emacs?
>
>
> best,
>
>
> lj
>
>
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>

> Then I think we should add the concept of score language plugins.
> Pfields for opcodes names that are not one character thingies such as we
> currently have would be dispatched to opcodes. There would be builtins
> based on CMask etc. The API for plugins would essentially bring into the
> plugin callback the current instance of Csound, from which all else
> could be done via the existing Csound API. I don't think this would
> require huge changes to the Csound language or parser.
>
> What do you think, all?

I think what you said earlier is true: this would eventually lead to yet 
another language. In that case, better design it as such from the 
beginning, else there is the risk that it becomes very ugly over time.

Personnaly I'm happy with the current state of Csound score. I generate 
scores transparently from much higher-level abstractions written in Lisp 
and/or Smalltalk and I can't see how a Csound score language would be 
more expressive than that.

Stef

I've probably discussed this on this list before, but I tend to think
about Csound score as a data format/protocol rather than a language.
It's something which is very detailed and easy to write as well as
easy to create tools for.  I also think that there are a number of
ways to think about music, and that's expressed in the tools we use.
Some prefer graphical tools, some prefer declarative text formats,
others text as code.

In Blue, I've built a number of different tools to support various
ways of generating notes.  One can write Python, Clojure, or
JavaScript code to generate notes, write Csound SCO text directly, use
CMask, nGen, or other external commandline tools, use GUI PianoRolls
and PatternEditors, etc.  In a way, this isn't so different than
Michael's proposal for score plugins, as these are all plugins in
Blue.  However, considering the system, what all of these higher level
tools have in common is that they ultimately generate standard Csound
SCO notes.

I'd rather have Csound maintain SCO text as a very small and well
understood format.  I don't think in terms of overall musical system
design, that it should be within Csound that we have plugins for score
processing, but rather at higher architectural levels, such as within
a host program.  This keeps the dependencies for Csound much smaller,
keeps the architecture simpler, and makes it easier to maintain.

If the goal is to have a single text file with multiple score
languages, it would certainly be possible to create a host program
that does preprocessing of the text file, then uses that to compile
down to something Csound can use.  It would even be possible to add an
additional API layer on top of the current Csound API (i.e.
libcsound+) that could load score language plugins, have additional
methods like ProcessScore(text), and have that in turn call the
low-level Csound API.  That way, at least the core of Csound could
remain very simple and clean.

steven

On Fri, Mar 15, 2013 at 11:41 PM, Stéphane Rollandin
 wrote:
>> Then I think we should add the concept of score language plugins.
>> Pfields for opcodes names that are not one character thingies such as we
>> currently have would be dispatched to opcodes. There would be builtins
>> based on CMask etc. The API for plugins would essentially bring into the
>> plugin callback the current instance of Csound, from which all else
>> could be done via the existing Csound API. I don't think this would
>> require huge changes to the Csound language or parser.
>>
>> What do you think, all?
>
>
> I think what you said earlier is true: this would eventually lead to yet
> another language. In that case, better design it as such from the beginning,
> else there is the risk that it becomes very ugly over time.
>
> Personnaly I'm happy with the current state of Csound score. I generate
> scores transparently from much higher-level abstractions written in Lisp
> and/or Smalltalk and I can't see how a Csound score language would be more
> expressive than that.
>
> Stef
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>            https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>

thanks for your answer, steven! 

apart from being an enthusiastic user of vim, i can't contribute much,
really. but i know there are several ways to use vim in a REPL. 
perhaps some of the more knowledgeable vim users could give a hint?

I agree, I am quite happy with the Csound score as it is. Its simplicity 
is its strongest point imho. However, for most every composition I use 
Cmask for score synthesis.

Just throwing an idea out there regarding merging the two, I could see a 
possibility of being able to create an instrument in the orc file that 
stipulates mask constraints that could be used in a pfield. This 
instrument could be inserted into one or more pfields for any given 
instrument of the score and would stipulate the mask constraints for it. 
Then the carry command could continue the results of the varying 
quasi-random output of the mask instrument on until it is ended.

Just one possibility.



On 3/15/13 7:41 PM, Stéphane Rollandin wrote:
>> Then I think we should add the concept of score language plugins.
>> Pfields for opcodes names that are not one character thingies such as we
>> currently have would be dispatched to opcodes. There would be builtins
>> based on CMask etc. The API for plugins would essentially bring into the
>> plugin callback the current instance of Csound, from which all else
>> could be done via the existing Csound API. I don't think this would
>> require huge changes to the Csound language or parser.
>>
>> What do you think, all?
>
> I think what you said earlier is true: this would eventually lead to 
> yet another language. In that case, better design it as such from the 
> beginning, else there is the risk that it becomes very ugly over time.
>
> Personnaly I'm happy with the current state of Csound score. I 
> generate scores transparently from much higher-level abstractions 
> written in Lisp and/or Smalltalk and I can't see how a Csound score 
> language would be more expressive than that.
>
> Stef
>
>
> Send bugs reports to the Sourceforge bug tracker
> https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body 
> "unsubscribe csound"
>
>

All I am proposing is adding functionality to the score. Nothing that has
been discussed would preclude using external score generators, nor would it
necessarily make the score format overly complicated or "ugly." I don't
think anyone would suggest that the addition of score expressions, for
example, was a bad idea, even though such computations are easy to implement
in a score generator. (In fact, I think they're ugly! But they are also
convenient sometimes.) We have always made sure that every new version of
Csound would still run legacy instruments, so I am confident that if we
added score language plugins, we would do so in a responsible,
backwards-compatible way.

> -----Original Message-----
> From: Michael Rhoades [mailto:mrhoades@perceptionfactory.com]
> Sent: Friday, March 15, 2013 8:17 PM
> To: csound@lists.bath.ac.uk
> Subject: Re: [Csnd] Csound 6 - Live Coding Demo
> 
> I agree, I am quite happy with the Csound score as it is. Its simplicity
> is its strongest point imho. However, for most every composition I use
> Cmask for score synthesis.
> 
> Just throwing an idea out there regarding merging the two, I could see a
> possibility of being able to create an instrument in the orc file that
> stipulates mask constraints that could be used in a pfield. This
> instrument could be inserted into one or more pfields for any given
> instrument of the score and would stipulate the mask constraints for it.
> Then the carry command could continue the results of the varying
> quasi-random output of the mask instrument on until it is ended.
> 
> Just one possibility.
> 
> 
> 
> On 3/15/13 7:41 PM, Stéphane Rollandin wrote:
> >> Then I think we should add the concept of score language plugins.
> >> Pfields for opcodes names that are not one character thingies such as
> we
> >> currently have would be dispatched to opcodes. There would be builtins
> >> based on CMask etc. The API for plugins would essentially bring into
> the
> >> plugin callback the current instance of Csound, from which all else
> >> could be done via the existing Csound API. I don't think this would
> >> require huge changes to the Csound language or parser.
> >>
> >> What do you think, all?
> >
> > I think what you said earlier is true: this would eventually lead to
> > yet another language. In that case, better design it as such from the
> > beginning, else there is the risk that it becomes very ugly over time.
> >
> > Personnaly I'm happy with the current state of Csound score. I
> > generate scores transparently from much higher-level abstractions
> > written in Lisp and/or Smalltalk and I can't see how a Csound score
> > language would be more expressive than that.
> >
> > Stef
> >
> >
> > Send bugs reports to the Sourceforge bug tracker
> > https://sourceforge.net/tracker/?group_id=81968&atid=564599
> > Discussions of bugs and features can be posted here
> > To unsubscribe, send email sympa@lists.bath.ac.uk with body
> > "unsubscribe csound"
> >
> >
> 
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"

I'm happy with the way it is.  I think the time would be better spent
on improving the GUIs.  With Csound6, there are a lot of new
possibilities for GUIs.  Live coding in text editors is nice but
making GUIs that leverage the new features will be much nicer.  IMO
that's what is going to attract people to Csound the most.  Csound
very much needs a solid GUI that allows wiring instruments together
graphically without having to stop and restart the audio on every
change.  This is now possible with Csound6.  The GUIs should leverage
this feature ASAP.  This is a significantly higher priority than score
plugins, imo.

Cheers,
~ andy.f



On Fri, Mar 15, 2013 at 10:55 PM, Russell Pinkston
 wrote:
> All I am proposing is adding functionality to the score. Nothing that has
> been discussed would preclude using external score generators, nor would it
> necessarily make the score format overly complicated or "ugly." I don't
> think anyone would suggest that the addition of score expressions, for
> example, was a bad idea, even though such computations are easy to implement
> in a score generator. (In fact, I think they're ugly! But they are also
> convenient sometimes.) We have always made sure that every new version of
> Csound would still run legacy instruments, so I am confident that if we
> added score language plugins, we would do so in a responsible,
> backwards-compatible way.
>
>> -----Original Message-----
>> From: Michael Rhoades [mailto:mrhoades@perceptionfactory.com]
>> Sent: Friday, March 15, 2013 8:17 PM
>> To: csound@lists.bath.ac.uk
>> Subject: Re: [Csnd] Csound 6 - Live Coding Demo
>>
>> I agree, I am quite happy with the Csound score as it is. Its simplicity
>> is its strongest point imho. However, for most every composition I use
>> Cmask for score synthesis.
>>
>> Just throwing an idea out there regarding merging the two, I could see a
>> possibility of being able to create an instrument in the orc file that
>> stipulates mask constraints that could be used in a pfield. This
>> instrument could be inserted into one or more pfields for any given
>> instrument of the score and would stipulate the mask constraints for it.
>> Then the carry command could continue the results of the varying
>> quasi-random output of the mask instrument on until it is ended.
>>
>> Just one possibility.
>>
>>
>>
>> On 3/15/13 7:41 PM, Stéphane Rollandin wrote:
>> >> Then I think we should add the concept of score language plugins.
>> >> Pfields for opcodes names that are not one character thingies such as
>> we
>> >> currently have would be dispatched to opcodes. There would be builtins
>> >> based on CMask etc. The API for plugins would essentially bring into
>> the
>> >> plugin callback the current instance of Csound, from which all else
>> >> could be done via the existing Csound API. I don't think this would
>> >> require huge changes to the Csound language or parser.
>> >>
>> >> What do you think, all?
>> >
>> > I think what you said earlier is true: this would eventually lead to
>> > yet another language. In that case, better design it as such from the
>> > beginning, else there is the risk that it becomes very ugly over time.
>> >
>> > Personnaly I'm happy with the current state of Csound score. I
>> > generate scores transparently from much higher-level abstractions
>> > written in Lisp and/or Smalltalk and I can't see how a Csound score
>> > language would be more expressive than that.
>> >
>> > Stef
>> >
>> >
>> > Send bugs reports to the Sourceforge bug tracker
>> > https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> > Discussions of bugs and features can be posted here
>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> > "unsubscribe csound"
>> >
>> >
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>

I understand the need to continue current functionality and legacy 
support. I was not suggesting abandoning it. However, it "might" be 
nice, if it is not too ugly, to be able to generate cmask type score 
events within the orc/sco or csd environment.

What kinds of additional functionality were you proposing? What are the 
possibilities? How would a score language plugin work and what would the 
benefits be? Please excuse my ignorance.



On 3/15/13 10:55 PM, Russell Pinkston wrote:
> All I am proposing is adding functionality to the score. Nothing that has
> been discussed would preclude using external score generators, nor would it
> necessarily make the score format overly complicated or "ugly." I don't
> think anyone would suggest that the addition of score expressions, for
> example, was a bad idea, even though such computations are easy to implement
> in a score generator. (In fact, I think they're ugly! But they are also
> convenient sometimes.) We have always made sure that every new version of
> Csound would still run legacy instruments, so I am confident that if we
> added score language plugins, we would do so in a responsible,
> backwards-compatible way.
>
>> -----Original Message-----
>> From: Michael Rhoades [mailto:mrhoades@perceptionfactory.com]
>> Sent: Friday, March 15, 2013 8:17 PM
>> To: csound@lists.bath.ac.uk
>> Subject: Re: [Csnd] Csound 6 - Live Coding Demo
>>
>> I agree, I am quite happy with the Csound score as it is. Its simplicity
>> is its strongest point imho. However, for most every composition I use
>> Cmask for score synthesis.
>>
>> Just throwing an idea out there regarding merging the two, I could see a
>> possibility of being able to create an instrument in the orc file that
>> stipulates mask constraints that could be used in a pfield. This
>> instrument could be inserted into one or more pfields for any given
>> instrument of the score and would stipulate the mask constraints for it.
>> Then the carry command could continue the results of the varying
>> quasi-random output of the mask instrument on until it is ended.
>>
>> Just one possibility.
>>

s it happens I have already started reimplementing the score language (not
not very far yet), so it may be possible to incorporate new things if
there is a consensus.  Should add that finishing cs6 is higher priority at
present

==John ff

> I understand the need to continue current functionality and legacy
> support. I was not suggesting abandoning it. However, it "might" be
> nice, if it is not too ugly, to be able to generate cmask type score
> events within the orc/sco or csd environment.
>
> What kinds of additional functionality were you proposing? What are the
> possibilities? How would a score language plugin work and what would the
> benefits be? Please excuse my ignorance.
>
>
>
> On 3/15/13 10:55 PM, Russell Pinkston wrote:
>> All I am proposing is adding functionality to the score. Nothing that
>> has
>> been discussed would preclude using external score generators, nor would
>> it
>> necessarily make the score format overly complicated or "ugly." I don't
>> think anyone would suggest that the addition of score expressions, for
>> example, was a bad idea, even though such computations are easy to
>> implement
>> in a score generator. (In fact, I think they're ugly! But they are also
>> convenient sometimes.) We have always made sure that every new version
>> of
>> Csound would still run legacy instruments, so I am confident that if we
>> added score language plugins, we would do so in a responsible,
>> backwards-compatible way.
>>
>>> -----Original Message-----
>>> From: Michael Rhoades [mailto:mrhoades@perceptionfactory.com]
>>> Sent: Friday, March 15, 2013 8:17 PM
>>> To: csound@lists.bath.ac.uk
>>> Subject: Re: [Csnd] Csound 6 - Live Coding Demo
>>>
>>> I agree, I am quite happy with the Csound score as it is. Its
>>> simplicity
>>> is its strongest point imho. However, for most every composition I use
>>> Cmask for score synthesis.
>>>
>>> Just throwing an idea out there regarding merging the two, I could see
>>> a
>>> possibility of being able to create an instrument in the orc file that
>>> stipulates mask constraints that could be used in a pfield. This
>>> instrument could be inserted into one or more pfields for any given
>>> instrument of the score and would stipulate the mask constraints for
>>> it.
>>> Then the carry command could continue the results of the varying
>>> quasi-random output of the mask instrument on until it is ended.
>>>
>>> Just one possibility.
>>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>
>
>

this is exactly my opinion.
	joachim


Am 16.03.2013 01:32, schrieb Steven Yi:
> I've probably discussed this on this list before, but I tend to think
> about Csound score as a data format/protocol rather than a language.
> It's something which is very detailed and easy to write as well as
> easy to create tools for.  I also think that there are a number of
> ways to think about music, and that's expressed in the tools we use.
> Some prefer graphical tools, some prefer declarative text formats,
> others text as code.
>
> In Blue, I've built a number of different tools to support various
> ways of generating notes.  One can write Python, Clojure, or
> JavaScript code to generate notes, write Csound SCO text directly, use
> CMask, nGen, or other external commandline tools, use GUI PianoRolls
> and PatternEditors, etc.  In a way, this isn't so different than
> Michael's proposal for score plugins, as these are all plugins in
> Blue.  However, considering the system, what all of these higher level
> tools have in common is that they ultimately generate standard Csound
> SCO notes.
>
> I'd rather have Csound maintain SCO text as a very small and well
> understood format.  I don't think in terms of overall musical system
> design, that it should be within Csound that we have plugins for score
> processing, but rather at higher architectural levels, such as within
> a host program.  This keeps the dependencies for Csound much smaller,
> keeps the architecture simpler, and makes it easier to maintain.
>
> If the goal is to have a single text file with multiple score
> languages, it would certainly be possible to create a host program
> that does preprocessing of the text file, then uses that to compile
> down to something Csound can use.  It would even be possible to add an
> additional API layer on top of the current Csound API (i.e.
> libcsound+) that could load score language plugins, have additional
> methods like ProcessScore(text), and have that in turn call the
> low-level Csound API.  That way, at least the core of Csound could
> remain very simple and clean.
>
> steven
>
> On Fri, Mar 15, 2013 at 11:41 PM, Stéphane Rollandin
>  wrote:
>>> Then I think we should add the concept of score language plugins.
>>> Pfields for opcodes names that are not one character thingies such as we
>>> currently have would be dispatched to opcodes. There would be builtins
>>> based on CMask etc. The API for plugins would essentially bring into the
>>> plugin callback the current instance of Csound, from which all else
>>> could be done via the existing Csound API. I don't think this would
>>> require huge changes to the Csound language or parser.
>>>
>>> What do you think, all?
>>
>>
>> I think what you said earlier is true: this would eventually lead to yet
>> another language. In that case, better design it as such from the beginning,
>> else there is the risk that it becomes very ugly over time.
>>
>> Personnaly I'm happy with the current state of Csound score. I generate
>> scores transparently from much higher-level abstractions written in Lisp
>> and/or Smalltalk and I can't see how a Csound score language would be more
>> expressive than that.
>>
>> Stef
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>              https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>

yes, i have already tested string arrays in csound 6 alpha. i wanted to 
send you an example, but now it does not work any more. i will report 
this on the dev list.

	joachim

Am 16.03.2013 00:06, schrieb Rory Walsh:
> Going back to a point Joachim made, now is probably the best time to
> discuss such conventions and how they can be brought into the future
> of the language as we move ever closer towards Csound 6. I love the
> addition of the until loop and I can see already see how using arrays
> will completely change the way I work with Csound. I still think a
> more Csound like endloop keyword would make it more accessible. Are
> stings arrays also possible?
>
>
>
> On 15 March 2013 22:52,   wrote:
>> If this is integrated into emacs I might even use live coding......
>>
>>>
>>> on 2013-03-15 at 00:14 Steven Yi wrote:
>>>
>>>> I was doing some testing tonight and thought I'd post a video of some
>>>> live coding with Csound 6:
>>>
>>> this is really great, steven, thanks for posting. makes me realize how far
>>> behind the recent advances of csound i am...
>>>
>>> this "csound editor" is an application you developed for OSX? could
>>> something like this be achieved from a standard "power" editor like vim or
>>> emacs?
>>>
>>>
>>> best,
>>>
>>>
>>> lj
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>              https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>              https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>>
>
>
> Send bugs reports to the Sourceforge bug tracker
>              https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>
>

Here is my suggestion for how score opcodes could work. Plugins and
builtins would work the same way. Plugins would be loaded by the
existing module loading code.

The general syntax would be:

opcodename pfield,...

There would be a variable allocator that would create a floating point
number with the assigned name. Other opcodes would be able to refer to
variables by these names.

init variablename [initialvalue]

Then there would be a trigger generator. This would change the value
of the trigger value starting at p2 and continuing to p2 + p3 at every
increment of duration,

init mytrigger
init duration .25
trigger mytrigger 1 20 duration

All of the other CMask type opcodes would take a first pfield to act
as a trigger. They would fire whenever the value of the trigger
changes.

This following would interpolate rampvalue from 1 to 10 whenever
mytrigger changes.

ramp trigger value starttime startvalue stoptime stopvalue

So, one would use ramp like this:

init ramper
; interpolate the value of "ramper" from 1 at 1 beats to 10 at 20 beats
ramp mytrigger ramper 1 1 10 20

This one does what the example from the cmask manual does:

init p1 1
init p2
trigger p2 1 10 .01 .2 prec 3
init p3
md p2, p3, p2, exp, 1
mask p2 p3, 0.5, 1, prec, 2
init p4
heap p2 p4 120 125 400 355
init p5
rnd p2 p5 uni
mask p2 p5 3 100 8 50 200 map 1
init p6
osc p2 p6 cos 0 .5 10 5

The above just gets stuff happening in the pfields. We need another
opcode to actually generate events based on these values (CMask itself
doesn't need such an opcode). One event is generated every time one of
the pfields changes.

event p1 p2 p3 p4 p5

No doubt I have made wrong assumptions or mistakes here but I hope
this gets some of the ideas across.

Regards,
Mike

On Sat, Mar 16, 2013 at 9:09 AM,  wrote:
>
> s it happens I have already started reimplementing the score language (not
> not very far yet), so it may be possible to incorporate new things if
> there is a consensus.  Should add that finishing cs6 is higher priority at
> present
>
> ==John ff
>
> > I understand the need to continue current functionality and legacy
> > support. I was not suggesting abandoning it. However, it "might" be
> > nice, if it is not too ugly, to be able to generate cmask type score
> > events within the orc/sco or csd environment.
> >
> > What kinds of additional functionality were you proposing? What are the
> > possibilities? How would a score language plugin work and what would the
> > benefits be? Please excuse my ignorance.
> >
> >
> >
> > On 3/15/13 10:55 PM, Russell Pinkston wrote:
> >> All I am proposing is adding functionality to the score. Nothing that
> >> has
> >> been discussed would preclude using external score generators, nor would
> >> it
> >> necessarily make the score format overly complicated or "ugly." I don't
> >> think anyone would suggest that the addition of score expressions, for
> >> example, was a bad idea, even though such computations are easy to
> >> implement
> >> in a score generator. (In fact, I think they're ugly! But they are also
> >> convenient sometimes.) We have always made sure that every new version
> >> of
> >> Csound would still run legacy instruments, so I am confident that if we
> >> added score language plugins, we would do so in a responsible,
> >> backwards-compatible way.
> >>
> >>> -----Original Message-----
> >>> From: Michael Rhoades [mailto:mrhoades@perceptionfactory.com]
> >>> Sent: Friday, March 15, 2013 8:17 PM
> >>> To: csound@lists.bath.ac.uk
> >>> Subject: Re: [Csnd] Csound 6 - Live Coding Demo
> >>>
> >>> I agree, I am quite happy with the Csound score as it is. Its
> >>> simplicity
> >>> is its strongest point imho. However, for most every composition I use
> >>> Cmask for score synthesis.
> >>>
> >>> Just throwing an idea out there regarding merging the two, I could see
> >>> a
> >>> possibility of being able to create an instrument in the orc file that
> >>> stipulates mask constraints that could be used in a pfield. This
> >>> instrument could be inserted into one or more pfields for any given
> >>> instrument of the score and would stipulate the mask constraints for
> >>> it.
> >>> Then the carry command could continue the results of the varying
> >>> quasi-random output of the mask instrument on until it is ended.
> >>>
> >>> Just one possibility.
> >>>
> >
> >
> > Send bugs reports to the Sourceforge bug tracker
> >             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> > Discussions of bugs and features can be posted here
> > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> > csound"
> >
> >
> >
> >
>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>



--
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

Thanks, Michael. I need to study this more carefully, but I can see one
immediate disadvantage to this approach, in terms of CMASK, specifically.
Existing CMASK files would have to be converted to this format, line by
line. I realize that CMASK is a special case, so perhaps it would be a
mistake to make allowances for it. Still, it has been around for a long time
and many people have used it extensively and are familiar with its syntax,
so it would be ideal if there was some convenient way to directly import
existing files. Moreover, assuming it was OK with Andre Bartetzki, it ought
to be possible to use much of his code directly. The suggestion I made
yesterday (of adding a new set of CSD tags) had that idea in mind. Another
thought I had was to implement something comparable to the system opcode,
which would allow users to shell out to a (well-behaved) standalone program,
whose output could be inserted at that point in the score, or even streamed,
much like schedule and event presumably work. Perhaps these suggestions are
impractical, but I thought I would throw them out there.

BTW, I think there's one typo/mistake in your example:

md p2, p3, p2, exp, 1

I believe it should be:

rnd p2 p3 p2 exp 1

Regards,
Russell

> -----Original Message-----
> From: Michael Gogins [mailto:michael.gogins@gmail.com]
> Sent: Saturday, March 16, 2013 12:15 PM
> To: Csound
> Subject: Re: [Csnd] Csound 6 - Live Coding Demo
> 
> Here is my suggestion for how score opcodes could work. Plugins and
> builtins would work the same way. Plugins would be loaded by the
> existing module loading code.
> 
> The general syntax would be:
> 
> opcodename pfield,...
> 
> There would be a variable allocator that would create a floating point
> number with the assigned name. Other opcodes would be able to refer to
> variables by these names.
> 
> init variablename [initialvalue]
> 
> Then there would be a trigger generator. This would change the value
> of the trigger value starting at p2 and continuing to p2 + p3 at every
> increment of duration,
> 
> init mytrigger
> init duration .25
> trigger mytrigger 1 20 duration
> 
> All of the other CMask type opcodes would take a first pfield to act
> as a trigger. They would fire whenever the value of the trigger
> changes.
> 
> This following would interpolate rampvalue from 1 to 10 whenever
> mytrigger changes.
> 
> ramp trigger value starttime startvalue stoptime stopvalue
> 
> So, one would use ramp like this:
> 
> init ramper
> ; interpolate the value of "ramper" from 1 at 1 beats to 10 at 20 beats
> ramp mytrigger ramper 1 1 10 20
> 
> This one does what the example from the cmask manual does:
> 
> init p1 1
> init p2
> trigger p2 1 10 .01 .2 prec 3
> init p3
> md p2, p3, p2, exp, 1
> mask p2 p3, 0.5, 1, prec, 2
> init p4
> heap p2 p4 120 125 400 355
> init p5
> rnd p2 p5 uni
> mask p2 p5 3 100 8 50 200 map 1
> init p6
> osc p2 p6 cos 0 .5 10 5
> 
> The above just gets stuff happening in the pfields. We need another
> opcode to actually generate events based on these values (CMask itself
> doesn't need such an opcode). One event is generated every time one of
> the pfields changes.
> 
> event p1 p2 p3 p4 p5
> 
> No doubt I have made wrong assumptions or mistakes here but I hope
> this gets some of the ideas across.
> 
> Regards,
> Mike
> 
> On Sat, Mar 16, 2013 at 9:09 AM,  wrote:
> >
> > s it happens I have already started reimplementing the score language
> (not
> > not very far yet), so it may be possible to incorporate new things if
> > there is a consensus.  Should add that finishing cs6 is higher priority
> at
> > present
> >
> > ==John ff
> >
> > > I understand the need to continue current functionality and legacy
> > > support. I was not suggesting abandoning it. However, it "might" be
> > > nice, if it is not too ugly, to be able to generate cmask type score
> > > events within the orc/sco or csd environment.
> > >
> > > What kinds of additional functionality were you proposing? What are
> the
> > > possibilities? How would a score language plugin work and what would
> the
> > > benefits be? Please excuse my ignorance.
> > >
> > >
> > >
> > > On 3/15/13 10:55 PM, Russell Pinkston wrote:
> > >> All I am proposing is adding functionality to the score. Nothing that
> > >> has
> > >> been discussed would preclude using external score generators, nor
> would
> > >> it
> > >> necessarily make the score format overly complicated or "ugly." I
> don't
> > >> think anyone would suggest that the addition of score expressions,
> for
> > >> example, was a bad idea, even though such computations are easy to
> > >> implement
> > >> in a score generator. (In fact, I think they're ugly! But they are
> also
> > >> convenient sometimes.) We have always made sure that every new
> version
> > >> of
> > >> Csound would still run legacy instruments, so I am confident that if
> we
> > >> added score language plugins, we would do so in a responsible,
> > >> backwards-compatible way.
> > >>
> > >>> -----Original Message-----
> > >>> From: Michael Rhoades [mailto:mrhoades@perceptionfactory.com]
> > >>> Sent: Friday, March 15, 2013 8:17 PM
> > >>> To: csound@lists.bath.ac.uk
> > >>> Subject: Re: [Csnd] Csound 6 - Live Coding Demo
> > >>>
> > >>> I agree, I am quite happy with the Csound score as it is. Its
> > >>> simplicity
> > >>> is its strongest point imho. However, for most every composition I
> use
> > >>> Cmask for score synthesis.
> > >>>
> > >>> Just throwing an idea out there regarding merging the two, I could
> see
> > >>> a
> > >>> possibility of being able to create an instrument in the orc file
> that
> > >>> stipulates mask constraints that could be used in a pfield. This
> > >>> instrument could be inserted into one or more pfields for any given
> > >>> instrument of the score and would stipulate the mask constraints for
> > >>> it.
> > >>> Then the carry command could continue the results of the varying
> > >>> quasi-random output of the mask instrument on until it is ended.
> > >>>
> > >>> Just one possibility.
> > >>>
> > >
> > >
> > > Send bugs reports to the Sourceforge bug tracker
> > >
> https://sourceforge.net/tracker/?group_id=81968&atid=564599
> > > Discussions of bugs and features can be posted here
> > > To unsubscribe, send email sympa@lists.bath.ac.uk with body
> "unsubscribe
> > > csound"
> > >
> > >
> > >
> > >
> >
> >
> >
> >
> > Send bugs reports to the Sourceforge bug tracker
> >             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> > Discussions of bugs and features can be posted here
> > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
> >
> 
> 
> 
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"

But you can use CMask as is, and CMask files as is, in a regular csd
file, like this:






;; bells.orc
;; ----------------------------------------
sr 	= 44100
kr 	= 4410
nchnls 	= 2

instr 1
	;p2 onset
	;p3 duration
	;p4 base frequency
	;p5 fm index
	;p6 pan (L=0, R=1)

kenv	expon	1,p3,0.01
kindx	expon	p5,p3,.4
a1	foscil	kenv*10000,p4,1,1.143,kindx,1
	outs	a1*(1-p6),a1*p6
endin	
;; ----------------------------------------


;; bells parameter file
;; ----------------------------------------
{
f1 0 8193 10 1            ;sine wave for foscil
}

f 0 20                    ;field 1

p1 const 1

p2 range -.2 .2           ;density difference -200 to +200 ms
accum limit .01 1         ;absolut values between .01 to 1 sec

p3 range -.1 .1 		
accum mirror .1 1.5 init .5	

p4 range -50 100          ;tendency to higher frequencies
accum wrap 200 2000 init 300  ;but wrapped at (upper) boundary

p5 const 3                ;FM index = 3

p6 range 0 1 prec 2	

;; ----------------------------------------



At least, this is supposed to work -- on my new Windows 8 system,
CMask starts to run but crashes after generating the .sco file (it
does get that far) so Csound can't finish. But you get the idea. CMask
just needs to be debugged and fixed up for this to work fine.

Regards,
Mike


On Sat, Mar 16, 2013 at 2:32 PM, Russell Pinkston
 wrote:
> Thanks, Michael. I need to study this more carefully, but I can see one
> immediate disadvantage to this approach, in terms of CMASK, specifically.
> Existing CMASK files would have to be converted to this format, line by
> line. I realize that CMASK is a special case, so perhaps it would be a
> mistake to make allowances for it. Still, it has been around for a long time
> and many people have used it extensively and are familiar with its syntax,
> so it would be ideal if there was some convenient way to directly import
> existing files. Moreover, assuming it was OK with Andre Bartetzki, it ought
> to be possible to use much of his code directly. The suggestion I made
> yesterday (of adding a new set of CSD tags) had that idea in mind. Another
> thought I had was to implement something comparable to the system opcode,
> which would allow users to shell out to a (well-behaved) standalone program,
> whose output could be inserted at that point in the score, or even streamed,
> much like schedule and event presumably work. Perhaps these suggestions are
> impractical, but I thought I would throw them out there.
>
> BTW, I think there's one typo/mistake in your example:
>
> md p2, p3, p2, exp, 1
>
> I believe it should be:
>
> rnd p2 p3 p2 exp 1
>
> Regards,
> Russell
>
>> -----Original Message-----
>> From: Michael Gogins [mailto:michael.gogins@gmail.com]
>> Sent: Saturday, March 16, 2013 12:15 PM
>> To: Csound
>> Subject: Re: [Csnd] Csound 6 - Live Coding Demo
>>
>> Here is my suggestion for how score opcodes could work. Plugins and
>> builtins would work the same way. Plugins would be loaded by the
>> existing module loading code.
>>
>> The general syntax would be:
>>
>> opcodename pfield,...
>>
>> There would be a variable allocator that would create a floating point
>> number with the assigned name. Other opcodes would be able to refer to
>> variables by these names.
>>
>> init variablename [initialvalue]
>>
>> Then there would be a trigger generator. This would change the value
>> of the trigger value starting at p2 and continuing to p2 + p3 at every
>> increment of duration,
>>
>> init mytrigger
>> init duration .25
>> trigger mytrigger 1 20 duration
>>
>> All of the other CMask type opcodes would take a first pfield to act
>> as a trigger. They would fire whenever the value of the trigger
>> changes.
>>
>> This following would interpolate rampvalue from 1 to 10 whenever
>> mytrigger changes.
>>
>> ramp trigger value starttime startvalue stoptime stopvalue
>>
>> So, one would use ramp like this:
>>
>> init ramper
>> ; interpolate the value of "ramper" from 1 at 1 beats to 10 at 20 beats
>> ramp mytrigger ramper 1 1 10 20
>>
>> This one does what the example from the cmask manual does:
>>
>> init p1 1
>> init p2
>> trigger p2 1 10 .01 .2 prec 3
>> init p3
>> md p2, p3, p2, exp, 1
>> mask p2 p3, 0.5, 1, prec, 2
>> init p4
>> heap p2 p4 120 125 400 355
>> init p5
>> rnd p2 p5 uni
>> mask p2 p5 3 100 8 50 200 map 1
>> init p6
>> osc p2 p6 cos 0 .5 10 5
>>
>> The above just gets stuff happening in the pfields. We need another
>> opcode to actually generate events based on these values (CMask itself
>> doesn't need such an opcode). One event is generated every time one of
>> the pfields changes.
>>
>> event p1 p2 p3 p4 p5
>>
>> No doubt I have made wrong assumptions or mistakes here but I hope
>> this gets some of the ideas across.
>>
>> Regards,
>> Mike
>>
>> On Sat, Mar 16, 2013 at 9:09 AM,  wrote:
>> >
>> > s it happens I have already started reimplementing the score language
>> (not
>> > not very far yet), so it may be possible to incorporate new things if
>> > there is a consensus.  Should add that finishing cs6 is higher priority
>> at
>> > present
>> >
>> > ==John ff
>> >
>> > > I understand the need to continue current functionality and legacy
>> > > support. I was not suggesting abandoning it. However, it "might" be
>> > > nice, if it is not too ugly, to be able to generate cmask type score
>> > > events within the orc/sco or csd environment.
>> > >
>> > > What kinds of additional functionality were you proposing? What are
>> the
>> > > possibilities? How would a score language plugin work and what would
>> the
>> > > benefits be? Please excuse my ignorance.
>> > >
>> > >
>> > >
>> > > On 3/15/13 10:55 PM, Russell Pinkston wrote:
>> > >> All I am proposing is adding functionality to the score. Nothing that
>> > >> has
>> > >> been discussed would preclude using external score generators, nor
>> would
>> > >> it
>> > >> necessarily make the score format overly complicated or "ugly." I
>> don't
>> > >> think anyone would suggest that the addition of score expressions,
>> for
>> > >> example, was a bad idea, even though such computations are easy to
>> > >> implement
>> > >> in a score generator. (In fact, I think they're ugly! But they are
>> also
>> > >> convenient sometimes.) We have always made sure that every new
>> version
>> > >> of
>> > >> Csound would still run legacy instruments, so I am confident that if
>> we
>> > >> added score language plugins, we would do so in a responsible,
>> > >> backwards-compatible way.
>> > >>
>> > >>> -----Original Message-----
>> > >>> From: Michael Rhoades [mailto:mrhoades@perceptionfactory.com]
>> > >>> Sent: Friday, March 15, 2013 8:17 PM
>> > >>> To: csound@lists.bath.ac.uk
>> > >>> Subject: Re: [Csnd] Csound 6 - Live Coding Demo
>> > >>>
>> > >>> I agree, I am quite happy with the Csound score as it is. Its
>> > >>> simplicity
>> > >>> is its strongest point imho. However, for most every composition I
>> use
>> > >>> Cmask for score synthesis.
>> > >>>
>> > >>> Just throwing an idea out there regarding merging the two, I could
>> see
>> > >>> a
>> > >>> possibility of being able to create an instrument in the orc file
>> that
>> > >>> stipulates mask constraints that could be used in a pfield. This
>> > >>> instrument could be inserted into one or more pfields for any given
>> > >>> instrument of the score and would stipulate the mask constraints for
>> > >>> it.
>> > >>> Then the carry command could continue the results of the varying
>> > >>> quasi-random output of the mask instrument on until it is ended.
>> > >>>
>> > >>> Just one possibility.
>> > >>>
>> > >
>> > >
>> > > Send bugs reports to the Sourceforge bug tracker
>> > >
>> https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> > > Discussions of bugs and features can be posted here
>> > > To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> "unsubscribe
>> > > csound"
>> > >
>> > >
>> > >
>> > >
>> >
>> >
>> >
>> >
>> > Send bugs reports to the Sourceforge bug tracker
>> >             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> > Discussions of bugs and features can be posted here
>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>> >
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

I was thinking of something similar except making the code work from the 
orc... something like below perhaps:

;orc
sr         = 44100
kr         = 4410
ksmps  = 10
nchnls  = 2



instr 1

iamp            =    p4
ifreq            =    p5
iwaveform    =    p6

a1 oscili    iamp,    ifreq,    iwaveform

      outs     a1,    a1
endin



instr 2        ;cmask instrument

;f 0 15        - now in sco dependant on p2 and p3;

;p1 const 1    - now in sco dependent on p1;

p2             ;istart
rnd uni
mask (0 2.35 12 3.65) (0 3.05 12 5.09)
prec 2

p3            ;idur
rnd uni
mask (0 6 12 8.4) (0 8 12 12)
prec 2

p4             ;iamp
rnd uni
range 5000 10000
prec 0

p5            ;ifreq
rnd uni
range  440    880
prec 0

p6            ;iwaveform
rnd uni
range 0 4
prec 0

endin




;sco

f1 0 16384 10 1
f2 0 16384 10 1 0.5 0.3 0.25 0.2 0.167 0.14 0.125 .111
f3 0 16384 10 1 0   0.3 0    0.2 0     0.14 0     .111
f4 0 16384 10 1 1   1   1    0.7 0.5   0.3  0.1

t 0 60


i1    0    10    10000    440        2     ;standard score event
i1    5    10    10000    220               ;standard score event
i1    10  10    10000    880        4     ;standard score event
i1    15  10    10000    440        3     ;standard score event
i1    20  20    i2                                ;uses i2(cmask) code 
to generate pfields for next p3 seconds

e

Wow! I had no idea you could do this, but it's right there in the Unified
File Format documentation, now that I look at it. RTFM! ;-)

> -----Original Message-----
> From: Michael Gogins [mailto:michael.gogins@gmail.com]
> Sent: Saturday, March 16, 2013 2:14 PM
> To: csound@lists.bath.ac.uk
> Subject: Re: [Csnd] Csound 6 - Live Coding Demo
> 
> But you can use CMask as is, and CMask files as is, in a regular csd
> file, like this:
> 
> 
> 
> 
> 
> 
> ;; bells.orc
> ;; ----------------------------------------
> sr 	= 44100
> kr 	= 4410
> nchnls 	= 2
> 
> instr 1
> 	;p2 onset
> 	;p3 duration
> 	;p4 base frequency
> 	;p5 fm index
> 	;p6 pan (L=0, R=1)
> 
> kenv	expon	1,p3,0.01
> kindx	expon	p5,p3,.4
> a1	foscil	kenv*10000,p4,1,1.143,kindx,1
> 	outs	a1*(1-p6),a1*p6
> endin
> ;; ----------------------------------------
> 
> 
> ;; bells parameter file
> ;; ----------------------------------------
> {
> f1 0 8193 10 1            ;sine wave for foscil
> }
> 
> f 0 20                    ;field 1
> 
> p1 const 1
> 
> p2 range -.2 .2           ;density difference -200 to +200 ms
> accum limit .01 1         ;absolut values between .01 to 1 sec
> 
> p3 range -.1 .1
> accum mirror .1 1.5 init .5
> 
> p4 range -50 100          ;tendency to higher frequencies
> accum wrap 200 2000 init 300  ;but wrapped at (upper) boundary
> 
> p5 const 3                ;FM index = 3
> 
> p6 range 0 1 prec 2
> 
> ;; ----------------------------------------
> 
> 
> 
> At least, this is supposed to work -- on my new Windows 8 system,
> CMask starts to run but crashes after generating the .sco file (it
> does get that far) so Csound can't finish. But you get the idea. CMask
> just needs to be debugged and fixed up for this to work fine.
> 
> Regards,
> Mike
> 
> 
> On Sat, Mar 16, 2013 at 2:32 PM, Russell Pinkston
>  wrote:
> > Thanks, Michael. I need to study this more carefully, but I can see one
> > immediate disadvantage to this approach, in terms of CMASK,
> specifically.
> > Existing CMASK files would have to be converted to this format, line by
> > line. I realize that CMASK is a special case, so perhaps it would be a
> > mistake to make allowances for it. Still, it has been around for a long
> time
> > and many people have used it extensively and are familiar with its
> syntax,
> > so it would be ideal if there was some convenient way to directly import
> > existing files. Moreover, assuming it was OK with Andre Bartetzki, it
> ought
> > to be possible to use much of his code directly. The suggestion I made
> > yesterday (of adding a new set of CSD tags) had that idea in mind.
> Another
> > thought I had was to implement something comparable to the system
> opcode,
> > which would allow users to shell out to a (well-behaved) standalone
> program,
> > whose output could be inserted at that point in the score, or even
> streamed,
> > much like schedule and event presumably work. Perhaps these suggestions
> are
> > impractical, but I thought I would throw them out there.
> >
> > BTW, I think there's one typo/mistake in your example:
> >
> > md p2, p3, p2, exp, 1
> >
> > I believe it should be:
> >
> > rnd p2 p3 p2 exp 1
> >
> > Regards,
> > Russell
> >
> >> -----Original Message-----
> >> From: Michael Gogins [mailto:michael.gogins@gmail.com]
> >> Sent: Saturday, March 16, 2013 12:15 PM
> >> To: Csound
> >> Subject: Re: [Csnd] Csound 6 - Live Coding Demo
> >>
> >> Here is my suggestion for how score opcodes could work. Plugins and
> >> builtins would work the same way. Plugins would be loaded by the
> >> existing module loading code.
> >>
> >> The general syntax would be:
> >>
> >> opcodename pfield,...
> >>
> >> There would be a variable allocator that would create a floating point
> >> number with the assigned name. Other opcodes would be able to refer to
> >> variables by these names.
> >>
> >> init variablename [initialvalue]
> >>
> >> Then there would be a trigger generator. This would change the value
> >> of the trigger value starting at p2 and continuing to p2 + p3 at every
> >> increment of duration,
> >>
> >> init mytrigger
> >> init duration .25
> >> trigger mytrigger 1 20 duration
> >>
> >> All of the other CMask type opcodes would take a first pfield to act
> >> as a trigger. They would fire whenever the value of the trigger
> >> changes.
> >>
> >> This following would interpolate rampvalue from 1 to 10 whenever
> >> mytrigger changes.
> >>
> >> ramp trigger value starttime startvalue stoptime stopvalue
> >>
> >> So, one would use ramp like this:
> >>
> >> init ramper
> >> ; interpolate the value of "ramper" from 1 at 1 beats to 10 at 20 beats
> >> ramp mytrigger ramper 1 1 10 20
> >>
> >> This one does what the example from the cmask manual does:
> >>
> >> init p1 1
> >> init p2
> >> trigger p2 1 10 .01 .2 prec 3
> >> init p3
> >> md p2, p3, p2, exp, 1
> >> mask p2 p3, 0.5, 1, prec, 2
> >> init p4
> >> heap p2 p4 120 125 400 355
> >> init p5
> >> rnd p2 p5 uni
> >> mask p2 p5 3 100 8 50 200 map 1
> >> init p6
> >> osc p2 p6 cos 0 .5 10 5
> >>
> >> The above just gets stuff happening in the pfields. We need another
> >> opcode to actually generate events based on these values (CMask itself
> >> doesn't need such an opcode). One event is generated every time one of
> >> the pfields changes.
> >>
> >> event p1 p2 p3 p4 p5
> >>
> >> No doubt I have made wrong assumptions or mistakes here but I hope
> >> this gets some of the ideas across.
> >>
> >> Regards,
> >> Mike
> >>
> >> On Sat, Mar 16, 2013 at 9:09 AM,  wrote:
> >> >
> >> > s it happens I have already started reimplementing the score language
> >> (not
> >> > not very far yet), so it may be possible to incorporate new things if
> >> > there is a consensus.  Should add that finishing cs6 is higher
> priority
> >> at
> >> > present
> >> >
> >> > ==John ff
> >> >
> >> > > I understand the need to continue current functionality and legacy
> >> > > support. I was not suggesting abandoning it. However, it "might" be
> >> > > nice, if it is not too ugly, to be able to generate cmask type
> score
> >> > > events within the orc/sco or csd environment.
> >> > >
> >> > > What kinds of additional functionality were you proposing? What are
> >> the
> >> > > possibilities? How would a score language plugin work and what
> would
> >> the
> >> > > benefits be? Please excuse my ignorance.
> >> > >
> >> > >
> >> > >
> >> > > On 3/15/13 10:55 PM, Russell Pinkston wrote:
> >> > >> All I am proposing is adding functionality to the score. Nothing
> that
> >> > >> has
> >> > >> been discussed would preclude using external score generators, nor
> >> would
> >> > >> it
> >> > >> necessarily make the score format overly complicated or "ugly." I
> >> don't
> >> > >> think anyone would suggest that the addition of score expressions,
> >> for
> >> > >> example, was a bad idea, even though such computations are easy to
> >> > >> implement
> >> > >> in a score generator. (In fact, I think they're ugly! But they are
> >> also
> >> > >> convenient sometimes.) We have always made sure that every new
> >> version
> >> > >> of
> >> > >> Csound would still run legacy instruments, so I am confident that
> if
> >> we
> >> > >> added score language plugins, we would do so in a responsible,
> >> > >> backwards-compatible way.
> >> > >>
> >> > >>> -----Original Message-----
> >> > >>> From: Michael Rhoades [mailto:mrhoades@perceptionfactory.com]
> >> > >>> Sent: Friday, March 15, 2013 8:17 PM
> >> > >>> To: csound@lists.bath.ac.uk
> >> > >>> Subject: Re: [Csnd] Csound 6 - Live Coding Demo
> >> > >>>
> >> > >>> I agree, I am quite happy with the Csound score as it is. Its
> >> > >>> simplicity
> >> > >>> is its strongest point imho. However, for most every composition
> I
> >> use
> >> > >>> Cmask for score synthesis.
> >> > >>>
> >> > >>> Just throwing an idea out there regarding merging the two, I
> could
> >> see
> >> > >>> a
> >> > >>> possibility of being able to create an instrument in the orc file
> >> that
> >> > >>> stipulates mask constraints that could be used in a pfield. This
> >> > >>> instrument could be inserted into one or more pfields for any
> given
> >> > >>> instrument of the score and would stipulate the mask constraints
> for
> >> > >>> it.
> >> > >>> Then the carry command could continue the results of the varying
> >> > >>> quasi-random output of the mask instrument on until it is ended.
> >> > >>>
> >> > >>> Just one possibility.
> >> > >>>
> >> > >
> >> > >
> >> > > Send bugs reports to the Sourceforge bug tracker
> >> > >
> >> https://sourceforge.net/tracker/?group_id=81968&atid=564599
> >> > > Discussions of bugs and features can be posted here
> >> > > To unsubscribe, send email sympa@lists.bath.ac.uk with body
> >> "unsubscribe
> >> > > csound"
> >> > >
> >> > >
> >> > >
> >> > >
> >> >
> >> >
> >> >
> >> >
> >> > Send bugs reports to the Sourceforge bug tracker
> >> >
> https://sourceforge.net/tracker/?group_id=81968&atid=564599
> >> > Discussions of bugs and features can be posted here
> >> > To unsubscribe, send email sympa@lists.bath.ac.uk with body
> "unsubscribe
> >> csound"
> >> >
> >>
> >>
> >>
> >> --
> >> Michael Gogins
> >> Irreducible Productions
> >> http://www.michael-gogins.com
> >> Michael dot Gogins at gmail dot com
> >>
> >>
> >> Send bugs reports to the Sourceforge bug tracker
> >>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> >> Discussions of bugs and features can be posted here
> >> To unsubscribe, send email sympa@lists.bath.ac.uk with body
> "unsubscribe
> >> csound"
> >
> >
> >
> > Send bugs reports to the Sourceforge bug tracker
> >             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> > Discussions of bugs and features can be posted here
> > To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
> >
> 
> 
> 
> --
> Michael Gogins
> Irreducible Productions
> http://www.michael-gogins.com
> Michael dot Gogins at gmail dot com
> 
> 
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"

yes,
in linux ubuntu 12.04 32 bit with csound 5.19 double it works.

ciao,
francesco.




--
View this message in context: http://csound.1045644.n5.nabble.com/Csound-6-Live-Coding-Demo-tp5721064p5721197.html
Sent from the Csound - General mailing list archive at Nabble.com.

It does not work as cmask expects a file not stdin
It needs a wrapper to cmask.  Actually looking into this

]
> Wow! I had no idea you could do this, but it's right there in the Unified
> File Format documentation, now that I look at it. RTFM! ;-)
>
>> -----Original Message-----
>> From: Michael Gogins [mailto:michael.gogins@gmail.com]
>> Sent: Saturday, March 16, 2013 2:14 PM
>> To: csound@lists.bath.ac.uk
>> Subject: Re: [Csnd] Csound 6 - Live Coding Demo
>>
>> But you can use CMask as is, and CMask files as is, in a regular csd
>> file, like this:
>>
>>
>> 
>> 
>> 
>> 
>> ;; bells.orc
>> ;; ----------------------------------------
>> sr 	= 44100
>> kr 	= 4410
>> nchnls 	= 2
>>
>> instr 1
>> 	;p2 onset
>> 	;p3 duration
>> 	;p4 base frequency
>> 	;p5 fm index
>> 	;p6 pan (L=0, R=1)
>>
>> kenv	expon	1,p3,0.01
>> kindx	expon	p5,p3,.4
>> a1	foscil	kenv*10000,p4,1,1.143,kindx,1
>> 	outs	a1*(1-p6),a1*p6
>> endin
>> ;; ----------------------------------------
>> 
>> 
>> ;; bells parameter file
>> ;; ----------------------------------------
>> {
>> f1 0 8193 10 1            ;sine wave for foscil
>> }
>>
>> f 0 20                    ;field 1
>>
>> p1 const 1
>>
>> p2 range -.2 .2           ;density difference -200 to +200 ms
>> accum limit .01 1         ;absolut values between .01 to 1 sec
>>
>> p3 range -.1 .1
>> accum mirror .1 1.5 init .5
>>
>> p4 range -50 100          ;tendency to higher frequencies
>> accum wrap 200 2000 init 300  ;but wrapped at (upper) boundary
>>
>> p5 const 3                ;FM index = 3
>>
>> p6 range 0 1 prec 2
>>
>> ;; ----------------------------------------
>> 
>> 
>>
>> At least, this is supposed to work -- on my new Windows 8 system,
>> CMask starts to run but crashes after generating the .sco file (it
>> does get that far) so Csound can't finish. But you get the idea. CMask
>> just needs to be debugged and fixed up for this to work fine.
>>
>> Regards,
>> Mike
>>
>>
>> On Sat, Mar 16, 2013 at 2:32 PM, Russell Pinkston
>>  wrote:
>> > Thanks, Michael. I need to study this more carefully, but I can see
>> one
>> > immediate disadvantage to this approach, in terms of CMASK,
>> specifically.
>> > Existing CMASK files would have to be converted to this format, line
>> by
>> > line. I realize that CMASK is a special case, so perhaps it would be a
>> > mistake to make allowances for it. Still, it has been around for a
>> long
>> time
>> > and many people have used it extensively and are familiar with its
>> syntax,
>> > so it would be ideal if there was some convenient way to directly
>> import
>> > existing files. Moreover, assuming it was OK with Andre Bartetzki, it
>> ought
>> > to be possible to use much of his code directly. The suggestion I made
>> > yesterday (of adding a new set of CSD tags) had that idea in mind.
>> Another
>> > thought I had was to implement something comparable to the system
>> opcode,
>> > which would allow users to shell out to a (well-behaved) standalone
>> program,
>> > whose output could be inserted at that point in the score, or even
>> streamed,
>> > much like schedule and event presumably work. Perhaps these
>> suggestions
>> are
>> > impractical, but I thought I would throw them out there.
>> >
>> > BTW, I think there's one typo/mistake in your example:
>> >
>> > md p2, p3, p2, exp, 1
>> >
>> > I believe it should be:
>> >
>> > rnd p2 p3 p2 exp 1
>> >
>> > Regards,
>> > Russell
>> >
>> >> -----Original Message-----
>> >> From: Michael Gogins [mailto:michael.gogins@gmail.com]
>> >> Sent: Saturday, March 16, 2013 12:15 PM
>> >> To: Csound
>> >> Subject: Re: [Csnd] Csound 6 - Live Coding Demo
>> >>
>> >> Here is my suggestion for how score opcodes could work. Plugins and
>> >> builtins would work the same way. Plugins would be loaded by the
>> >> existing module loading code.
>> >>
>> >> The general syntax would be:
>> >>
>> >> opcodename pfield,...
>> >>
>> >> There would be a variable allocator that would create a floating
>> point
>> >> number with the assigned name. Other opcodes would be able to refer
>> to
>> >> variables by these names.
>> >>
>> >> init variablename [initialvalue]
>> >>
>> >> Then there would be a trigger generator. This would change the value
>> >> of the trigger value starting at p2 and continuing to p2 + p3 at
>> every
>> >> increment of duration,
>> >>
>> >> init mytrigger
>> >> init duration .25
>> >> trigger mytrigger 1 20 duration
>> >>
>> >> All of the other CMask type opcodes would take a first pfield to act
>> >> as a trigger. They would fire whenever the value of the trigger
>> >> changes.
>> >>
>> >> This following would interpolate rampvalue from 1 to 10 whenever
>> >> mytrigger changes.
>> >>
>> >> ramp trigger value starttime startvalue stoptime stopvalue
>> >>
>> >> So, one would use ramp like this:
>> >>
>> >> init ramper
>> >> ; interpolate the value of "ramper" from 1 at 1 beats to 10 at 20
>> beats
>> >> ramp mytrigger ramper 1 1 10 20
>> >>
>> >> This one does what the example from the cmask manual does:
>> >>
>> >> init p1 1
>> >> init p2
>> >> trigger p2 1 10 .01 .2 prec 3
>> >> init p3
>> >> md p2, p3, p2, exp, 1
>> >> mask p2 p3, 0.5, 1, prec, 2
>> >> init p4
>> >> heap p2 p4 120 125 400 355
>> >> init p5
>> >> rnd p2 p5 uni
>> >> mask p2 p5 3 100 8 50 200 map 1
>> >> init p6
>> >> osc p2 p6 cos 0 .5 10 5
>> >>
>> >> The above just gets stuff happening in the pfields. We need another
>> >> opcode to actually generate events based on these values (CMask
>> itself
>> >> doesn't need such an opcode). One event is generated every time one
>> of
>> >> the pfields changes.
>> >>
>> >> event p1 p2 p3 p4 p5
>> >>
>> >> No doubt I have made wrong assumptions or mistakes here but I hope
>> >> this gets some of the ideas across.
>> >>
>> >> Regards,
>> >> Mike
>> >>
>> >> On Sat, Mar 16, 2013 at 9:09 AM,  wrote:
>> >> >
>> >> > s it happens I have already started reimplementing the score
>> language
>> >> (not
>> >> > not very far yet), so it may be possible to incorporate new things
>> if
>> >> > there is a consensus.  Should add that finishing cs6 is higher
>> priority
>> >> at
>> >> > present
>> >> >
>> >> > ==John ff
>> >> >
>> >> > > I understand the need to continue current functionality and
>> legacy
>> >> > > support. I was not suggesting abandoning it. However, it "might"
>> be
>> >> > > nice, if it is not too ugly, to be able to generate cmask type
>> score
>> >> > > events within the orc/sco or csd environment.
>> >> > >
>> >> > > What kinds of additional functionality were you proposing? What
>> are
>> >> the
>> >> > > possibilities? How would a score language plugin work and what
>> would
>> >> the
>> >> > > benefits be? Please excuse my ignorance.
>> >> > >
>> >> > >
>> >> > >
>> >> > > On 3/15/13 10:55 PM, Russell Pinkston wrote:
>> >> > >> All I am proposing is adding functionality to the score. Nothing
>> that
>> >> > >> has
>> >> > >> been discussed would preclude using external score generators,
>> nor
>> >> would
>> >> > >> it
>> >> > >> necessarily make the score format overly complicated or "ugly."
>> I
>> >> don't
>> >> > >> think anyone would suggest that the addition of score
>> expressions,
>> >> for
>> >> > >> example, was a bad idea, even though such computations are easy
>> to
>> >> > >> implement
>> >> > >> in a score generator. (In fact, I think they're ugly! But they
>> are
>> >> also
>> >> > >> convenient sometimes.) We have always made sure that every new
>> >> version
>> >> > >> of
>> >> > >> Csound would still run legacy instruments, so I am confident
>> that
>> if
>> >> we
>> >> > >> added score language plugins, we would do so in a responsible,
>> >> > >> backwards-compatible way.
>> >> > >>
>> >> > >>> -----Original Message-----
>> >> > >>> From: Michael Rhoades [mailto:mrhoades@perceptionfactory.com]
>> >> > >>> Sent: Friday, March 15, 2013 8:17 PM
>> >> > >>> To: csound@lists.bath.ac.uk
>> >> > >>> Subject: Re: [Csnd] Csound 6 - Live Coding Demo
>> >> > >>>
>> >> > >>> I agree, I am quite happy with the Csound score as it is. Its
>> >> > >>> simplicity
>> >> > >>> is its strongest point imho. However, for most every
>> composition
>> I
>> >> use
>> >> > >>> Cmask for score synthesis.
>> >> > >>>
>> >> > >>> Just throwing an idea out there regarding merging the two, I
>> could
>> >> see
>> >> > >>> a
>> >> > >>> possibility of being able to create an instrument in the orc
>> file
>> >> that
>> >> > >>> stipulates mask constraints that could be used in a pfield.
>> This
>> >> > >>> instrument could be inserted into one or more pfields for any
>> given
>> >> > >>> instrument of the score and would stipulate the mask
>> constraints
>> for
>> >> > >>> it.
>> >> > >>> Then the carry command could continue the results of the
>> varying
>> >> > >>> quasi-random output of the mask instrument on until it is
>> ended.
>> >> > >>>
>> >> > >>> Just one possibility.
>> >> > >>>
>> >> > >
>> >> > >
>> >> > > Send bugs reports to the Sourceforge bug tracker
>> >> > >
>> >> https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >> > > Discussions of bugs and features can be posted here
>> >> > > To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> >> "unsubscribe
>> >> > > csound"
>> >> > >
>> >> > >
>> >> > >
>> >> > >
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > Send bugs reports to the Sourceforge bug tracker
>> >> >
>> https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >> > Discussions of bugs and features can be posted here
>> >> > To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> "unsubscribe
>> >> csound"
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Michael Gogins
>> >> Irreducible Productions
>> >> http://www.michael-gogins.com
>> >> Michael dot Gogins at gmail dot com
>> >>
>> >>
>> >> Send bugs reports to the Sourceforge bug tracker
>> >>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> >> Discussions of bugs and features can be posted here
>> >> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> "unsubscribe
>> >> csound"
>> >
>> >
>> >
>> > Send bugs reports to the Sourceforge bug tracker
>> >             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> > Discussions of bugs and features can be posted here
>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body
>> "unsubscribe
>> csound"
>> >
>>
>>
>>
>> --
>> Michael Gogins
>> Irreducible Productions
>> http://www.michael-gogins.com
>> Michael dot Gogins at gmail dot com
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
> csound"
>
>
>
>

I suggest bin=command file=filename

or

bin=command arg1=something arg2=else

or simply bin="command and optional args"

Regards,
Mike

On Sat, Mar 16, 2013 at 6:25 PM,   wrote:
> It does not work as cmask expects a file not stdin
> It needs a wrapper to cmask.  Actually looking into this
>
> ]
>> Wow! I had no idea you could do this, but it's right there in the Unified
>> File Format documentation, now that I look at it. RTFM! ;-)
>>
>>> -----Original Message-----
>>> From: Michael Gogins [mailto:michael.gogins@gmail.com]
>>> Sent: Saturday, March 16, 2013 2:14 PM
>>> To: csound@lists.bath.ac.uk
>>> Subject: Re: [Csnd] Csound 6 - Live Coding Demo
>>>
>>> But you can use CMask as is, and CMask files as is, in a regular csd
>>> file, like this:
>>>
>>>
>>> 
>>> 
>>> 
>>> 
>>> ;; bells.orc
>>> ;; ----------------------------------------
>>> sr   = 44100
>>> kr   = 4410
>>> nchnls       = 2
>>>
>>> instr 1
>>>      ;p2 onset
>>>      ;p3 duration
>>>      ;p4 base frequency
>>>      ;p5 fm index
>>>      ;p6 pan (L=0, R=1)
>>>
>>> kenv expon   1,p3,0.01
>>> kindx        expon   p5,p3,.4
>>> a1   foscil  kenv*10000,p4,1,1.143,kindx,1
>>>      outs    a1*(1-p6),a1*p6
>>> endin
>>> ;; ----------------------------------------
>>> 
>>> 
>>> ;; bells parameter file
>>> ;; ----------------------------------------
>>> {
>>> f1 0 8193 10 1            ;sine wave for foscil
>>> }
>>>
>>> f 0 20                    ;field 1
>>>
>>> p1 const 1
>>>
>>> p2 range -.2 .2           ;density difference -200 to +200 ms
>>> accum limit .01 1         ;absolut values between .01 to 1 sec
>>>
>>> p3 range -.1 .1
>>> accum mirror .1 1.5 init .5
>>>
>>> p4 range -50 100          ;tendency to higher frequencies
>>> accum wrap 200 2000 init 300  ;but wrapped at (upper) boundary
>>>
>>> p5 const 3                ;FM index = 3
>>>
>>> p6 range 0 1 prec 2
>>>
>>> ;; ----------------------------------------
>>> 
>>> 
>>>
>>> At least, this is supposed to work -- on my new Windows 8 system,
>>> CMask starts to run but crashes after generating the .sco file (it
>>> does get that far) so Csound can't finish. But you get the idea. CMask
>>> just needs to be debugged and fixed up for this to work fine.
>>>
>>> Regards,
>>> Mike
>>>
>>>
>>> On Sat, Mar 16, 2013 at 2:32 PM, Russell Pinkston
>>>  wrote:
>>> > Thanks, Michael. I need to study this more carefully, but I can see
>>> one
>>> > immediate disadvantage to this approach, in terms of CMASK,
>>> specifically.
>>> > Existing CMASK files would have to be converted to this format, line
>>> by
>>> > line. I realize that CMASK is a special case, so perhaps it would be a
>>> > mistake to make allowances for it. Still, it has been around for a
>>> long
>>> time
>>> > and many people have used it extensively and are familiar with its
>>> syntax,
>>> > so it would be ideal if there was some convenient way to directly
>>> import
>>> > existing files. Moreover, assuming it was OK with Andre Bartetzki, it
>>> ought
>>> > to be possible to use much of his code directly. The suggestion I made
>>> > yesterday (of adding a new set of CSD tags) had that idea in mind.
>>> Another
>>> > thought I had was to implement something comparable to the system
>>> opcode,
>>> > which would allow users to shell out to a (well-behaved) standalone
>>> program,
>>> > whose output could be inserted at that point in the score, or even
>>> streamed,
>>> > much like schedule and event presumably work. Perhaps these
>>> suggestions
>>> are
>>> > impractical, but I thought I would throw them out there.
>>> >
>>> > BTW, I think there's one typo/mistake in your example:
>>> >
>>> > md p2, p3, p2, exp, 1
>>> >
>>> > I believe it should be:
>>> >
>>> > rnd p2 p3 p2 exp 1
>>> >
>>> > Regards,
>>> > Russell
>>> >
>>> >> -----Original Message-----
>>> >> From: Michael Gogins [mailto:michael.gogins@gmail.com]
>>> >> Sent: Saturday, March 16, 2013 12:15 PM
>>> >> To: Csound
>>> >> Subject: Re: [Csnd] Csound 6 - Live Coding Demo
>>> >>
>>> >> Here is my suggestion for how score opcodes could work. Plugins and
>>> >> builtins would work the same way. Plugins would be loaded by the
>>> >> existing module loading code.
>>> >>
>>> >> The general syntax would be:
>>> >>
>>> >> opcodename pfield,...
>>> >>
>>> >> There would be a variable allocator that would create a floating
>>> point
>>> >> number with the assigned name. Other opcodes would be able to refer
>>> to
>>> >> variables by these names.
>>> >>
>>> >> init variablename [initialvalue]
>>> >>
>>> >> Then there would be a trigger generator. This would change the value
>>> >> of the trigger value starting at p2 and continuing to p2 + p3 at
>>> every
>>> >> increment of duration,
>>> >>
>>> >> init mytrigger
>>> >> init duration .25
>>> >> trigger mytrigger 1 20 duration
>>> >>
>>> >> All of the other CMask type opcodes would take a first pfield to act
>>> >> as a trigger. They would fire whenever the value of the trigger
>>> >> changes.
>>> >>
>>> >> This following would interpolate rampvalue from 1 to 10 whenever
>>> >> mytrigger changes.
>>> >>
>>> >> ramp trigger value starttime startvalue stoptime stopvalue
>>> >>
>>> >> So, one would use ramp like this:
>>> >>
>>> >> init ramper
>>> >> ; interpolate the value of "ramper" from 1 at 1 beats to 10 at 20
>>> beats
>>> >> ramp mytrigger ramper 1 1 10 20
>>> >>
>>> >> This one does what the example from the cmask manual does:
>>> >>
>>> >> init p1 1
>>> >> init p2
>>> >> trigger p2 1 10 .01 .2 prec 3
>>> >> init p3
>>> >> md p2, p3, p2, exp, 1
>>> >> mask p2 p3, 0.5, 1, prec, 2
>>> >> init p4
>>> >> heap p2 p4 120 125 400 355
>>> >> init p5
>>> >> rnd p2 p5 uni
>>> >> mask p2 p5 3 100 8 50 200 map 1
>>> >> init p6
>>> >> osc p2 p6 cos 0 .5 10 5
>>> >>
>>> >> The above just gets stuff happening in the pfields. We need another
>>> >> opcode to actually generate events based on these values (CMask
>>> itself
>>> >> doesn't need such an opcode). One event is generated every time one
>>> of
>>> >> the pfields changes.
>>> >>
>>> >> event p1 p2 p3 p4 p5
>>> >>
>>> >> No doubt I have made wrong assumptions or mistakes here but I hope
>>> >> this gets some of the ideas across.
>>> >>
>>> >> Regards,
>>> >> Mike
>>> >>
>>> >> On Sat, Mar 16, 2013 at 9:09 AM,  wrote:
>>> >> >
>>> >> > s it happens I have already started reimplementing the score
>>> language
>>> >> (not
>>> >> > not very far yet), so it may be possible to incorporate new things
>>> if
>>> >> > there is a consensus.  Should add that finishing cs6 is higher
>>> priority
>>> >> at
>>> >> > present
>>> >> >
>>> >> > ==John ff
>>> >> >
>>> >> > > I understand the need to continue current functionality and
>>> legacy
>>> >> > > support. I was not suggesting abandoning it. However, it "might"
>>> be
>>> >> > > nice, if it is not too ugly, to be able to generate cmask type
>>> score
>>> >> > > events within the orc/sco or csd environment.
>>> >> > >
>>> >> > > What kinds of additional functionality were you proposing? What
>>> are
>>> >> the
>>> >> > > possibilities? How would a score language plugin work and what
>>> would
>>> >> the
>>> >> > > benefits be? Please excuse my ignorance.
>>> >> > >
>>> >> > >
>>> >> > >
>>> >> > > On 3/15/13 10:55 PM, Russell Pinkston wrote:
>>> >> > >> All I am proposing is adding functionality to the score. Nothing
>>> that
>>> >> > >> has
>>> >> > >> been discussed would preclude using external score generators,
>>> nor
>>> >> would
>>> >> > >> it
>>> >> > >> necessarily make the score format overly complicated or "ugly."
>>> I
>>> >> don't
>>> >> > >> think anyone would suggest that the addition of score
>>> expressions,
>>> >> for
>>> >> > >> example, was a bad idea, even though such computations are easy
>>> to
>>> >> > >> implement
>>> >> > >> in a score generator. (In fact, I think they're ugly! But they
>>> are
>>> >> also
>>> >> > >> convenient sometimes.) We have always made sure that every new
>>> >> version
>>> >> > >> of
>>> >> > >> Csound would still run legacy instruments, so I am confident
>>> that
>>> if
>>> >> we
>>> >> > >> added score language plugins, we would do so in a responsible,
>>> >> > >> backwards-compatible way.
>>> >> > >>
>>> >> > >>> -----Original Message-----
>>> >> > >>> From: Michael Rhoades [mailto:mrhoades@perceptionfactory.com]
>>> >> > >>> Sent: Friday, March 15, 2013 8:17 PM
>>> >> > >>> To: csound@lists.bath.ac.uk
>>> >> > >>> Subject: Re: [Csnd] Csound 6 - Live Coding Demo
>>> >> > >>>
>>> >> > >>> I agree, I am quite happy with the Csound score as it is. Its
>>> >> > >>> simplicity
>>> >> > >>> is its strongest point imho. However, for most every
>>> composition
>>> I
>>> >> use
>>> >> > >>> Cmask for score synthesis.
>>> >> > >>>
>>> >> > >>> Just throwing an idea out there regarding merging the two, I
>>> could
>>> >> see
>>> >> > >>> a
>>> >> > >>> possibility of being able to create an instrument in the orc
>>> file
>>> >> that
>>> >> > >>> stipulates mask constraints that could be used in a pfield.
>>> This
>>> >> > >>> instrument could be inserted into one or more pfields for any
>>> given
>>> >> > >>> instrument of the score and would stipulate the mask
>>> constraints
>>> for
>>> >> > >>> it.
>>> >> > >>> Then the carry command could continue the results of the
>>> varying
>>> >> > >>> quasi-random output of the mask instrument on until it is
>>> ended.
>>> >> > >>>
>>> >> > >>> Just one possibility.
>>> >> > >>>
>>> >> > >
>>> >> > >
>>> >> > > Send bugs reports to the Sourceforge bug tracker
>>> >> > >
>>> >> https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> >> > > Discussions of bugs and features can be posted here
>>> >> > > To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>> >> "unsubscribe
>>> >> > > csound"
>>> >> > >
>>> >> > >
>>> >> > >
>>> >> > >
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > Send bugs reports to the Sourceforge bug tracker
>>> >> >
>>> https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> >> > Discussions of bugs and features can be posted here
>>> >> > To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>> "unsubscribe
>>> >> csound"
>>> >> >
>>> >>
>>> >>
>>> >>
>>> >> --
>>> >> Michael Gogins
>>> >> Irreducible Productions
>>> >> http://www.michael-gogins.com
>>> >> Michael dot Gogins at gmail dot com
>>> >>
>>> >>
>>> >> Send bugs reports to the Sourceforge bug tracker
>>> >>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> >> Discussions of bugs and features can be posted here
>>> >> To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>> "unsubscribe
>>> >> csound"
>>> >
>>> >
>>> >
>>> > Send bugs reports to the Sourceforge bug tracker
>>> >             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> > Discussions of bugs and features can be posted here
>>> > To unsubscribe, send email sympa@lists.bath.ac.uk with body
>>> "unsubscribe
>>> csound"
>>> >
>>>
>>>
>>>
>>> --
>>> Michael Gogins
>>> Irreducible Productions
>>> http://www.michael-gogins.com
>>> Michael dot Gogins at gmail dot com
>>>
>>>
>>> Send bugs reports to the Sourceforge bug tracker
>>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>>> Discussions of bugs and features can be posted here
>>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>>> csound"
>>
>>
>>
>>
>> Send bugs reports to the Sourceforge bug tracker
>>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
>> Discussions of bugs and features can be posted here
>> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe
>> csound"
>>
>>
>>
>>
>
>
>
>
> Send bugs reports to the Sourceforge bug tracker
>             https://sourceforge.net/tracker/?group_id=81968&atid=564599
> Discussions of bugs and features can be posted here
> To unsubscribe, send email sympa@lists.bath.ac.uk with body "unsubscribe csound"
>



-- 
Michael Gogins
Irreducible Productions
http://www.michael-gogins.com
Michael dot Gogins at gmail dot com

This is going to make writing Cabbage instruments a whole lot of fun!

sent from a mobile device...

it's also going to make working with any frontend a lot more interesting ;) the possibilities are crazy! We can build realtime development environments now.

sent from a mobile device...

Blue uses $infile and $outfile for the user to use when building external commands. It was added to get things working with cmask and nGen. More information about there mechanism here:

http://blue.kunstmusik.com/manual/html/externalSoundObject.html

I think this is a more general solution to the problem than trying to modify cmask and requiring users to update. Perhaps this can be used with the bin= command.