Hi All,

I've been thinking about some use cases for some instrument designs of
mine and have been contemplating optional named arguments for notes.
The idea I had was something like:

i1 0 4 3 articulation=4 label="test"

with instrument code such as:

instr 1
ival arg "articulation", 0  ; where 0 is a default value
Sval arg "label", "" ; where "" is a default
endin

This would be per-note values, and would be carried over when notes are tied.

Any thoughts on this?

Thanks!
steven

That would mean a potential rewrite of sread.c to accomodate for
argument names like this. Remember the score is not parser with
Flex/Bison.

On 2/7/12, Steven Yi  wrote:
> Hi All,
>
> I've been thinking about some use cases for some instrument designs of
> mine and have been contemplating optional named arguments for notes.
> The idea I had was something like:
>
> i1 0 4 3 articulation=4 label="test"
>
> with instrument code such as:
>
> instr 1
> ival arg "articulation", 0  ; where 0 is a default value
> Sval arg "label", "" ; where "" is a default
> endin
>
> This would be per-note values, and would be carried over when notes are
> tied.
>
> Any thoughts on this?
>
> Thanks!
> 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"
>
>

Yes, but that's not an issue.  Either updating sread or reimplementing
scores with flex/bison isn't going to interfere as things are going to
change up quite a bit all around for Csound 6.  I'm more interested in
comments on the syntax and mechanism of this, if anyone has
alternative suggestions or can see it useful for themselves as well.

On Tue, Feb 7, 2012 at 8:10 PM, Adam Puckett  wrote:
> That would mean a potential rewrite of sread.c to accomodate for
> argument names like this. Remember the score is not parser with
> Flex/Bison.
>
> On 2/7/12, Steven Yi  wrote:
>> Hi All,
>>
>> I've been thinking about some use cases for some instrument designs of
>> mine and have been contemplating optional named arguments for notes.
>> The idea I had was something like:
>>
>> i1 0 4 3 articulation=4 label="test"
>>
>> with instrument code such as:
>>
>> instr 1
>> ival arg "articulation", 0  ; where 0 is a default value
>> Sval arg "label", "" ; where "" is a default
>> endin
>>
>> This would be per-note values, and would be carried over when notes are
>> tied.
>>
>> Any thoughts on this?
>>
>> Thanks!
>> 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"
>

I gave this quite a bit of thought. My opinion is this:

1) yes, these features are really desirable

2) the current score syntax makes it awkward to implement them, I think your example does not really read very well

3) Why not consider developing a new score language which can be used alternatively to the old one, with support
for various new things? Given that the backwards compatibility is not an issue, we could design it from scratch and
implement it with flex/bison. It could be added to CSD files as a new block like this:






and we could also have an interpreter for RT events in this new language. Not that this does not replace the old numeric score, but
adds to it.

Alternatively, we could do away with a separate score for this new syntax and implement it as additions to the  orchestra
language.

I don't have a design to offer right now, but I am sure people would have suggestions about it.

Victor



On 7 Feb 2012, at 21:17, Steven Yi wrote:

> Yes, but that's not an issue.  Either updating sread or reimplementing
> scores with flex/bison isn't going to interfere as things are going to
> change up quite a bit all around for Csound 6.  I'm more interested in
> comments on the syntax and mechanism of this, if anyone has
> alternative suggestions or can see it useful for themselves as well.
> 
> On Tue, Feb 7, 2012 at 8:10 PM, Adam Puckett  wrote:
>> That would mean a potential rewrite of sread.c to accomodate for
>> argument names like this. Remember the score is not parser with
>> Flex/Bison.
>> 
>> On 2/7/12, Steven Yi  wrote:
>>> Hi All,
>>> 
>>> I've been thinking about some use cases for some instrument designs of
>>> mine and have been contemplating optional named arguments for notes.
>>> The idea I had was something like:
>>> 
>>> i1 0 4 3 articulation=4 label="test"
>>> 
>>> with instrument code such as:
>>> 
>>> instr 1
>>> ival arg "articulation", 0  ; where 0 is a default value
>>> Sval arg "label", "" ; where "" is a default
>>> endin
>>> 
>>> This would be per-note values, and would be carried over when notes are
>>> tied.
>>> 
>>> Any thoughts on this?
>>> 
>>> Thanks!
>>> 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"
> 

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




------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

For a long time a flex/bison score parser has been on my personal list of
ThingsToDo

> I gave this quite a bit of thought. My opinion is this:
>
> 1) yes, these features are really desirable
>
> 2) the current score syntax makes it awkward to implement them, I think
> your example does not really read very well
>
> 3) Why not consider developing a new score language which can be used
> alternatively to the old one, with support
> for various new things? Given that the backwards compatibility is not an
> issue, we could design it from scratch and
> implement it with flex/bison. It could be added to CSD files as a new
> block like this:
>
> 
>
>
> 
>
> and we could also have an interpreter for RT events in this new language.
> Not that this does not replace the old numeric score, but
> adds to it.
>
> Alternatively, we could do away with a separate score for this new syntax
> and implement it as additions to the  orchestra
> language.
>
> I don't have a design to offer right now, but I am sure people would have
> suggestions about it.
>
> Victor
>
>
>
> On 7 Feb 2012, at 21:17, Steven Yi wrote:
>
>> Yes, but that's not an issue.  Either updating sread or reimplementing
>> scores with flex/bison isn't going to interfere as things are going to
>> change up quite a bit all around for Csound 6.  I'm more interested in
>> comments on the syntax and mechanism of this, if anyone has
>> alternative suggestions or can see it useful for themselves as well.
>>
>> On Tue, Feb 7, 2012 at 8:10 PM, Adam Puckett 
>> wrote:
>>> That would mean a potential rewrite of sread.c to accomodate for
>>> argument names like this. Remember the score is not parser with
>>> Flex/Bison.
>>>
>>> On 2/7/12, Steven Yi  wrote:
>>>> Hi All,
>>>>
>>>> I've been thinking about some use cases for some instrument designs of
>>>> mine and have been contemplating optional named arguments for notes.
>>>> The idea I had was something like:
>>>>
>>>> i1 0 4 3 articulation=4 label="test"
>>>>
>>>> with instrument code such as:
>>>>
>>>> instr 1
>>>> ival arg "articulation", 0  ; where 0 is a default value
>>>> Sval arg "label", "" ; where "" is a default
>>>> endin
>>>>
>>>> This would be per-note values, and would be carried over when notes
>>>> are
>>>> tied.
>>>>
>>>> Any thoughts on this?
>>>>
>>>> Thanks!
>>>> 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"
>>
>
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: +353 1 708 3545
> Victor dot Lazzarini AT nuim dot ie
>
>
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
>
>



------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Hello,
It seems  a very welcome option to me - makes the score more readable and one does not need to worry in which p-field which parametwr sits.
Of course it would mean more typing and possible typos and with very many arguments it will become clumsy, but overall I personally like this idea very much!
Tarmo

looks promising!
what do you mean by the 99%?
	j

Am 08.02.2012 23:01, schrieb Tito Latini:
> The 1% of this can be good, the 99% irritates but can stimulate other ideas.
> 
> instr test1(amp, freq=1234, fn=1) [, ...]
>   out poscil3(amp, freq, fn)
> endin
> 
> instr test2 ...
> ...
> 
> instr test3 ...
> ...
> 
> instr test4(inst1, inst2, inst3, freq)
>   a1 = inst1(0.3 + inst2(0.3, freq*0.5), fn=2)
>   out a1 + inst3(0.7, freq + inst1(20, 8, 2))
> endin
> 
> pattern ft1(start)
>   f 1 start 8192 10 1
>   f 2 start 8192 10 1 4=0.1 8=0.01
> endpat
> 
> pattern intro(start, dur, tempo)
>   t 0 tempo
>   i test4  start  dur  test1  test2  test3   880
>   i test4  +       .     .    test3  test2  1200  
>   i test4  +       .   test2  test4  test1   220
>   i test4  at=[start+4.5]  dur=0.7  inst1=test3  inst2=test1  inst3=test2  freq=4321
> endpat
> 
> pattern phrA(start, dur), cmd="sbcl"
>   (format t "i test1 ~F ~F 0.7~%" start dur)
> endpat
> 
> pattern phrB(start, dur), cmd="runhaskell"
>   main = putStrLn $ "i test2 " ++ show(start) ++ " " ++ show(dur)
> endpat
> 
> pattern phrC(start, dur=0.75), cmd="python"
>   print "i test3", start, dur
> endpat
> 
> pattern phrD(start, end, d1), cmd="cmask"
>   f start end
>     p1 const 1
>     p2 rnd uni
>        mask [.08 .7 ipl 3] [.13 1.1 ipl 4] map 1
>        prec 3
>     p3 d1
> endpat
> 
> pattern phrE(start, events), cmd="score11"
>   i1 start 0 events;
>     p3 rh 4/8///8./16/(2=4/4/4),/2;
>     p4 no c4/e/g/b/cs5/;
>   end;
> endpat
> 
> pattern rec(start, dur, pch, n=0, end=4), stop when n==end
>   i test2 start dur [cpspch(pch+n*0.03)]
>   p rec [start+1] [dur*0.5] n++
> endpat
> 
> ...
> 
> pattern fiorito(start)
>   p ft1   start
>   p intro start 1 94
>   p intro [start+0.75] 1.3 102
>   p rec   [start+1]    2    8.00
>   p rec   [start+3]    4    7.00  0  8
>   p phrA  [start+7.2]  0.5
>   s
>   p phrB  start        0.5
>   p phrB  +            .
>   p phrC  [start+1]    0.88
>   p phrD  [start+1.5]  [start+12] 0.9
>   p phrE  [start+13] 8
>   ...
> endpat
> 
> ...
> 
> score
>   p fiorito 0
>   ...
>   e
> endsco
> 
> tito
> 
> On Wed, Feb 08, 2012 at 12:29:04PM +0000, Victor Lazzarini wrote:
>> I gave this quite a bit of thought. My opinion is this:
>>
>> 1) yes, these features are really desirable
>>
>> 2) the current score syntax makes it awkward to implement them, I think your example does not really read very well
>>
>> 3) Why not consider developing a new score language which can be used alternatively to the old one, with support
>> for various new things? Given that the backwards compatibility is not an issue, we could design it from scratch and
>> implement it with flex/bison. It could be added to CSD files as a new block like this:
>>
>> 
>>
>>
>> 
>>
>> and we could also have an interpreter for RT events in this new language. Not that this does not replace the old numeric score, but
>> adds to it.
>>
>> Alternatively, we could do away with a separate score for this new syntax and implement it as additions to the  orchestra
>> language.
>>
>> I don't have a design to offer right now, but I am sure people would have suggestions about it.
>>
>> Victor
>>
>>
>>
>> On 7 Feb 2012, at 21:17, Steven Yi wrote:
>>
>>> Yes, but that's not an issue.  Either updating sread or reimplementing
>>> scores with flex/bison isn't going to interfere as things are going to
>>> change up quite a bit all around for Csound 6.  I'm more interested in
>>> comments on the syntax and mechanism of this, if anyone has
>>> alternative suggestions or can see it useful for themselves as well.
>>>
>>> On Tue, Feb 7, 2012 at 8:10 PM, Adam Puckett  wrote:
>>>> That would mean a potential rewrite of sread.c to accomodate for
>>>> argument names like this. Remember the score is not parser with
>>>> Flex/Bison.
>>>>
>>>> On 2/7/12, Steven Yi  wrote:
>>>>> Hi All,
>>>>>
>>>>> I've been thinking about some use cases for some instrument designs of
>>>>> mine and have been contemplating optional named arguments for notes.
>>>>> The idea I had was something like:
>>>>>
>>>>> i1 0 4 3 articulation=4 label="test"
>>>>>
>>>>> with instrument code such as:
>>>>>
>>>>> instr 1
>>>>> ival arg "articulation", 0  ; where 0 is a default value
>>>>> Sval arg "label", "" ; where "" is a default
>>>>> endin
>>>>>
>>>>> This would be per-note values, and would be carried over when notes are
>>>>> tied.
>>>>>
>>>>> Any thoughts on this?
>>>>>
>>>>> Thanks!
>>>>> 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"
>>>
>>
>> Dr Victor Lazzarini
>> Senior Lecturer
>> Dept. of Music
>> NUI Maynooth Ireland
>> tel.: +353 1 708 3545
>> Victor dot Lazzarini AT nuim dot ie
> 
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 

------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

in my understanding, csound is an audio library with many possible ways
 (and open to new ones) to get access to it.
so i don't have the impression that "this code doesn't seem csound".
my impression is that it is one possible way for a future csound.
so, in my opinion, much more than 1%. but certainly something which
should be discussed further on to avoid too many branches.
best -
	j


Am 08.02.2012 23:42, schrieb Tito Latini:
>> looks promising!
>> what do you mean by the 99%?
> 
> You have an open mind but I think that this code doesn't seem csound.
> I didn't want to send it, then I have thought about the 1%
> 
> 
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
> 

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

+1
On 9 Feb 2012, at 08:50, Tito Latini wrote:

> After the following changes (from a Victor's list)
> 
>  - on-the-fly compilation, loading, unloading of instruments
>  - separation of compiler and engine
>  - 'compiled' orchestra representation for serialisation and loading of compiled code
> 
> many csounders will write a 'compiled' orchestra representation
> using their preferred language. Csound will become a good virus for
> the musical applications. I like a lot these three points and
> I think that all the energies must have used for realizing them.
> Later we can experiment externally all the variations that we want
> and to include them in csound if these are successful.
> 
> tito
> 
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing 
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel

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




------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

For me the most important enhancement will be the ability to compile a
complete Csound instrument definition in C++ and have it be loaded and
used in an ordinary Csound performance. A similar ability for Lua or
other efficient dynamic languages would also be nice but is not as
important.

Regards,
Mike

On Thu, Feb 9, 2012 at 4:37 AM, Victor Lazzarini
 wrote:
> +1
> On 9 Feb 2012, at 08:50, Tito Latini wrote:
>
>> After the following changes (from a Victor's list)
>>
>>  - on-the-fly compilation, loading, unloading of instruments
>>  - separation of compiler and engine
>>  - 'compiled' orchestra representation for serialisation and loading of compiled code
>>
>> many csounders will write a 'compiled' orchestra representation
>> using their preferred language. Csound will become a good virus for
>> the musical applications. I like a lot these three points and
>> I think that all the energies must have used for realizing them.
>> Later we can experiment externally all the variations that we want
>> and to include them in csound if these are successful.
>>
>> tito
>>
>> ------------------------------------------------------------------------------
>> Virtualization & Cloud Management Using Capacity Planning
>> Cloud computing makes use of virtualization - but cloud computing
>> also focuses on allowing computing to be delivered as a service.
>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>> _______________________________________________
>> Csound-devel mailing list
>> Csound-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/csound-devel
>
> Dr Victor Lazzarini
> Senior Lecturer
> Dept. of Music
> NUI Maynooth Ireland
> tel.: +353 1 708 3545
> Victor dot Lazzarini AT nuim dot ie
>
>
>
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel



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

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net