Csound › Csound - Dev

Re: [Csnd] Proposal: Optional Named Arguments for Notes

Classic

List

Threaded

10 messages Options

Victor Lazzarini

Re: [Csnd] Proposal: Optional Named Arguments for Notes

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:

<CsNewScore>

</CsNewScore>

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 <[hidden email]> 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 <[hidden email]> 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 [hidden email] 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 [hidden email] 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 [hidden email] 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

Remove Ads

jpff

Re: [Csnd] Proposal: Optional Named Arguments for Notes

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:
>
> <CsNewScore>
>
>
> </CsNewScore>
>
> 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 <[hidden email]>
>> 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 <[hidden email]> 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 [hidden email] 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 [hidden email] 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 [hidden email] 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

Tito Latini

Re: [Csnd] Proposal: Optional Named Arguments for Notes

In reply to this post by Victor Lazzarini

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:
>
> <CsNewScore>
>
>
> </CsNewScore>
>
> 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 <[hidden email]> 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 <[hidden email]> 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 [hidden email] 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 [hidden email] 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 [hidden email] 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

joachim-3

Re: [Csnd] Proposal: Optional Named Arguments for Notes

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:
>>
>> <CsNewScore>
>>
>>
>> </CsNewScore>
>>
>> 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 <[hidden email]> 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 <[hidden email]> 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 [hidden email] 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 [hidden email] 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 [hidden email] 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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/csound-devel
>

Tito Latini

Re: [Csnd] Proposal: Optional Named Arguments for Notes

> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

joachim-3

Re: [Csnd] Proposal: Optional Named Arguments for Notes

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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

Tito Latini

Re: [Csnd] Proposal: Optional Named Arguments for Notes

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

Victor Lazzarini

Re: [Csnd] Proposal: Optional Named Arguments for Notes

+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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

Michael Gogins-2

Re: [Csnd] Proposal: Optional Named Arguments for Notes

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
<[hidden email]> 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
>> [hidden email]
>> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel

Alex Weiss

Re: [Csnd] Proposal: Optional Named Arguments for Notes

In reply to this post by Tito Latini

This feels like Christmas. These are the three things I'm dying to have in csound! You guys are amazing.

Alex

On Thu, Feb 9, 2012 at 12:50 AM, Tito Latini <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/csound-devel