Hi everybody!

I'm Brian Simmons, one of Dr.B's Csound students at Berklee, and I
came up with an idea that might be worth looking into.

I was thinking of a way to use note duration values based on tempo,
like writing in quarter notes and eight notes in the p3 fields instead
of using time values in seconds.


These note duration would obviously have to be calculated based on a
new bpm (beats per minute) argument (some kind of value converter?)

I'm aware of the existence of macros, but I think having this tool be
a little bit more integrated into the Csound environment would be a
tremendous help for those that have even a very basic music theory
background.


This is the way I thought it would work:

So if we have set a bpm of 120 beats per minute, the p3 fields would
read and operate as following:


Bpm = 120

so then,  on your  p3:

to make a quarter note, you type in "4" in p3, and the value converter
should calculate   (1 * 60 / bpm)

which would yield a result of a 0.5 second note.


Other note values:

half note        =       2        the converter calculates  (2 * 60 / bpm)

whole note     =       1       the converter calculates  (4 * 60 / bpm)

8th note         =       8       the converter calculates  (0.5 * 60 / bpm)

16th note       =       16      the converter calculates  (0.25 * 60 / bpm)

32nd note     =        32      the converter calculates  (0.125 * 60 / bpm)


Then we would only be missing dotted notes, triplets, quintuplets,
ect; for these I was thinking you could use the value "4.1" for a
dotted quarter note and the value converter would calculate  (1.5 * 60
/ bpm)


double dotted quarter note  = 4.2        the converter calculates
(1.75 * 60 / bpm)

quarter note triplet               = 4.3        the converter
calculates (2/3 * 60/ bpm)

and so on, for the different time value alterations, (I can make a
full list of them with calculations if this whole idea is worth
pursuing).



Maybe some way to have different tempos at different sections of the
score would also be an interesting idea.

If something like this were to be implemented, it would seriously cut
down the time required to make very precise note durations on note
list scores based on a  variable tempo.


Thanks a lot for reading,


~Brian Simmons

Hi Brian,

There's been many interesting score languages and programs that
process text formats, some similarly to what you mentioned.  I think
overall though, the score format in Csound is best as-is, and other
layers of abstractions can be built on top of it.

Also, you could use t-statements to modify tempo for processing score.
 Using "t 0 120" sets the tempo to 120 bpm.  After that, score times
are in beats (actually, it's always in beats, with a default of 60
bpm).  You could use that to write scores such as .25 for sixteenths,
1 for quarters, 4 for whole notes, etc.  You could also use something
like "t 0 480" if you want to use 4 for quarters, and 1 for
sixteenths, etc.  All of that is already built into Csound today.

Thanks,
steven

On Mon, Mar 5, 2012 at 3:36 PM, Brian Simmons  wrote:
> Hi everybody!
>
> I'm Brian Simmons, one of Dr.B's Csound students at Berklee, and I
> came up with an idea that might be worth looking into.
>
> I was thinking of a way to use note duration values based on tempo,
> like writing in quarter notes and eight notes in the p3 fields instead
> of using time values in seconds.
>
>
> These note duration would obviously have to be calculated based on a
> new bpm (beats per minute) argument (some kind of value converter?)
>
> I'm aware of the existence of macros, but I think having this tool be
> a little bit more integrated into the Csound environment would be a
> tremendous help for those that have even a very basic music theory
> background.
>
>
> This is the way I thought it would work:
>
> So if we have set a bpm of 120 beats per minute, the p3 fields would
> read and operate as following:
>
>
> Bpm = 120
>
> so then,  on your  p3:
>
> to make a quarter note, you type in "4" in p3, and the value converter
> should calculate   (1 * 60 / bpm)
>
> which would yield a result of a 0.5 second note.
>
>
> Other note values:
>
> half note        =       2        the converter calculates  (2 * 60 / bpm)
>
> whole note     =       1       the converter calculates  (4 * 60 / bpm)
>
> 8th note         =       8       the converter calculates  (0.5 * 60 / bpm)
>
> 16th note       =       16      the converter calculates  (0.25 * 60 / bpm)
>
> 32nd note     =        32      the converter calculates  (0.125 * 60 / bpm)
>
>
> Then we would only be missing dotted notes, triplets, quintuplets,
> ect; for these I was thinking you could use the value "4.1" for a
> dotted quarter note and the value converter would calculate  (1.5 * 60
> / bpm)
>
>
> double dotted quarter note  = 4.2        the converter calculates
> (1.75 * 60 / bpm)
>
> quarter note triplet               = 4.3        the converter
> calculates (2/3 * 60/ bpm)
>
> and so on, for the different time value alterations, (I can make a
> full list of them with calculations if this whole idea is worth
> pursuing).
>
>
>
> Maybe some way to have different tempos at different sections of the
> score would also be an interesting idea.
>
> If something like this were to be implemented, it would seriously cut
> down the time required to make very precise note durations on note
> list scores based on a  variable tempo.
>
>
> Thanks a lot for reading,
>
>
> ~Brian Simmons
>
>
> 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 don't you think we need a value converter.  Not having one is like saying Freq in Hz is best and we don't need cpspch().  Linear amp is fine so we don't need 0dbfs or ampdb.  And we  certainly don't need any MIDI converters because it lacks precision and resolution?

Adding a sense of musical time to Csound is long overdue.  

Check out Maple7 by my student Brian Baughn for a good example of a completely worked out macro solution.  Still...  We really need this and better advance and Tempo support...  Like over sections.  

-dB

Sent from my iPhone.

On Mar 5, 2012, at 10:42 AM, Steven Yi  wrote:

> Hi Brian,
> 
> There's been many interesting score languages and programs that
> process text formats, some similarly to what you mentioned.  I think
> overall though, the score format in Csound is best as-is, and other
> layers of abstractions can be built on top of it.
> 
> Also, you could use t-statements to modify tempo for processing score.
> Using "t 0 120" sets the tempo to 120 bpm.  After that, score times
> are in beats (actually, it's always in beats, with a default of 60
> bpm).  You could use that to write scores such as .25 for sixteenths,
> 1 for quarters, 4 for whole notes, etc.  You could also use something
> like "t 0 480" if you want to use 4 for quarters, and 1 for
> sixteenths, etc.  All of that is already built into Csound today.
> 
> Thanks,
> steven
> 
> On Mon, Mar 5, 2012 at 3:36 PM, Brian Simmons  wrote:
>> Hi everybody!
>> 
>> I'm Brian Simmons, one of Dr.B's Csound students at Berklee, and I
>> came up with an idea that might be worth looking into.
>> 
>> I was thinking of a way to use note duration values based on tempo,
>> like writing in quarter notes and eight notes in the p3 fields instead
>> of using time values in seconds.
>> 
>> 
>> These note duration would obviously have to be calculated based on a
>> new bpm (beats per minute) argument (some kind of value converter?)
>> 
>> I'm aware of the existence of macros, but I think having this tool be
>> a little bit more integrated into the Csound environment would be a
>> tremendous help for those that have even a very basic music theory
>> background.
>> 
>> 
>> This is the way I thought it would work:
>> 
>> So if we have set a bpm of 120 beats per minute, the p3 fields would
>> read and operate as following:
>> 
>> 
>> Bpm = 120
>> 
>> so then,  on your  p3:
>> 
>> to make a quarter note, you type in "4" in p3, and the value converter
>> should calculate   (1 * 60 / bpm)
>> 
>> which would yield a result of a 0.5 second note.
>> 
>> 
>> Other note values:
>> 
>> half note        =       2        the converter calculates  (2 * 60 / bpm)
>> 
>> whole note     =       1       the converter calculates  (4 * 60 / bpm)
>> 
>> 8th note         =       8       the converter calculates  (0.5 * 60 / bpm)
>> 
>> 16th note       =       16      the converter calculates  (0.25 * 60 / bpm)
>> 
>> 32nd note     =        32      the converter calculates  (0.125 * 60 / bpm)
>> 
>> 
>> Then we would only be missing dotted notes, triplets, quintuplets,
>> ect; for these I was thinking you could use the value "4.1" for a
>> dotted quarter note and the value converter would calculate  (1.5 * 60
>> / bpm)
>> 
>> 
>> double dotted quarter note  = 4.2        the converter calculates
>> (1.75 * 60 / bpm)
>> 
>> quarter note triplet               = 4.3        the converter
>> calculates (2/3 * 60/ bpm)
>> 
>> and so on, for the different time value alterations, (I can make a
>> full list of them with calculations if this whole idea is worth
>> pursuing).
>> 
>> 
>> 
>> Maybe some way to have different tempos at different sections of the
>> score would also be an interesting idea.
>> 
>> If something like this were to be implemented, it would seriously cut
>> down the time required to make very precise note durations on note
>> list scores based on a  variable tempo.
>> 
>> 
>> Thanks a lot for reading,
>> 
>> 
>> ~Brian Simmons
>> 
>> 
>> 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 think that as long as there is as usual complete backwards
compatibility, then denominating times in musical units is a good
idea. But of course it should be well thought out. I think this would
have to come with opcodes in the sco language for meter and tuplet as
well as tempo. Perhaps time would be bar:beat and duration would be
beats:meter or something like that.

I think this is a very complex issue and needs careful consideration.
Let's have a look at MusicXML, MIDI, and commercial software to see
how they do it.

Regards,
Mike

On Mon, Mar 5, 2012 at 10:57 AM, Dr. Richard Boulanger
 wrote:
> But don't you think we need a value converter.  Not having one is like saying Freq in Hz is best and we don't need cpspch().  Linear amp is fine so we don't need 0dbfs or ampdb.  And we  certainly don't need any MIDI converters because it lacks precision and resolution?
>
> Adding a sense of musical time to Csound is long overdue.
>
> Check out Maple7 by my student Brian Baughn for a good example of a completely worked out macro solution.  Still...  We really need this and better advance and Tempo support...  Like over sections.
>
> -dB
>
> Sent from my iPhone.
>
> On Mar 5, 2012, at 10:42 AM, Steven Yi  wrote:
>
>> Hi Brian,
>>
>> There's been many interesting score languages and programs that
>> process text formats, some similarly to what you mentioned.  I think
>> overall though, the score format in Csound is best as-is, and other
>> layers of abstractions can be built on top of it.
>>
>> Also, you could use t-statements to modify tempo for processing score.
>> Using "t 0 120" sets the tempo to 120 bpm.  After that, score times
>> are in beats (actually, it's always in beats, with a default of 60
>> bpm).  You could use that to write scores such as .25 for sixteenths,
>> 1 for quarters, 4 for whole notes, etc.  You could also use something
>> like "t 0 480" if you want to use 4 for quarters, and 1 for
>> sixteenths, etc.  All of that is already built into Csound today.
>>
>> Thanks,
>> steven
>>
>> On Mon, Mar 5, 2012 at 3:36 PM, Brian Simmons  wrote:
>>> Hi everybody!
>>>
>>> I'm Brian Simmons, one of Dr.B's Csound students at Berklee, and I
>>> came up with an idea that might be worth looking into.
>>>
>>> I was thinking of a way to use note duration values based on tempo,
>>> like writing in quarter notes and eight notes in the p3 fields instead
>>> of using time values in seconds.
>>>
>>>
>>> These note duration would obviously have to be calculated based on a
>>> new bpm (beats per minute) argument (some kind of value converter?)
>>>
>>> I'm aware of the existence of macros, but I think having this tool be
>>> a little bit more integrated into the Csound environment would be a
>>> tremendous help for those that have even a very basic music theory
>>> background.
>>>
>>>
>>> This is the way I thought it would work:
>>>
>>> So if we have set a bpm of 120 beats per minute, the p3 fields would
>>> read and operate as following:
>>>
>>>
>>> Bpm = 120
>>>
>>> so then,  on your  p3:
>>>
>>> to make a quarter note, you type in "4" in p3, and the value converter
>>> should calculate   (1 * 60 / bpm)
>>>
>>> which would yield a result of a 0.5 second note.
>>>
>>>
>>> Other note values:
>>>
>>> half note        =       2        the converter calculates  (2 * 60 / bpm)
>>>
>>> whole note     =       1       the converter calculates  (4 * 60 / bpm)
>>>
>>> 8th note         =       8       the converter calculates  (0.5 * 60 / bpm)
>>>
>>> 16th note       =       16      the converter calculates  (0.25 * 60 / bpm)
>>>
>>> 32nd note     =        32      the converter calculates  (0.125 * 60 / bpm)
>>>
>>>
>>> Then we would only be missing dotted notes, triplets, quintuplets,
>>> ect; for these I was thinking you could use the value "4.1" for a
>>> dotted quarter note and the value converter would calculate  (1.5 * 60
>>> / bpm)
>>>
>>>
>>> double dotted quarter note  = 4.2        the converter calculates
>>> (1.75 * 60 / bpm)
>>>
>>> quarter note triplet               = 4.3        the converter
>>> calculates (2/3 * 60/ bpm)
>>>
>>> and so on, for the different time value alterations, (I can make a
>>> full list of them with calculations if this whole idea is worth
>>> pursuing).
>>>
>>>
>>>
>>> Maybe some way to have different tempos at different sections of the
>>> score would also be an interesting idea.
>>>
>>> If something like this were to be implemented, it would seriously cut
>>> down the time required to make very precise note durations on note
>>> list scores based on a  variable tempo.
>>>
>>>
>>> Thanks a lot for reading,
>>>
>>>
>>> ~Brian Simmons
>>>
>>>
>>> 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

I disagree, especially in regards to the comparisons.  This is apples
and oranges.  Csound disregards everything after p3, but p2 and p3 are
used in scheduling. Value converters for anything else is fine. In the
same way that MIDI doesn't have any abstractions for time, and
programs build on top of it using their own abstractions, do I see the
situation with Csound.  Having a second layer on top clearly--whether
it's macros, custom notations, etc.--shows the user that there is a
different notation of time than what is native to within Csound.

These kinds of things just don't belong in Csound core IMO, and belong
in other programs that build on top of it.  Otherwise, it's just going
to be a hack that doesn't ever satisfy everyone's use case, and will
cause just as many problems as it proposes to solve.

So I can't disagree more.  Otherwise, if you really want to change the
value of p3 to take in the proposed notation, you can do so with a
UDO.  (Example below).  Note though that you can't use this and use
things like + in your score, as the conversion happens at runtime.
Also note, that there's ultimately going to be cognitive dissonance
between p2 and p3, as start times will be in beats, while p3 is in
relative score durations.

steven





sr=44100
ksmps=64
0dbfs=1

opcode convertTime, i, i
itime xin
xout 4 / itime
endop

instr 1
itime convertTime p3
p3 = itime
ipch = cpspch(p4)
iamp = ampdbfs(p5)
aout vco2 iamp, ipch
aout moogladder aout, 4000, .05
outs aout, aout
endin



i1 0 4 8.00 -12
i1 1 4 8.03 .
i1 2 4 8.07 .
i1 3 1 9.00 .





On Mon, Mar 5, 2012 at 3:57 PM, Dr. Richard Boulanger
 wrote:
> But don't you think we need a value converter.  Not having one is like saying Freq in Hz is best and we don't need cpspch().  Linear amp is fine so we don't need 0dbfs or ampdb.  And we  certainly don't need any MIDI converters because it lacks precision and resolution?
>
> Adding a sense of musical time to Csound is long overdue.
>
> Check out Maple7 by my student Brian Baughn for a good example of a completely worked out macro solution.  Still...  We really need this and better advance and Tempo support...  Like over sections.
>
> -dB
>
> Sent from my iPhone.
>
> On Mar 5, 2012, at 10:42 AM, Steven Yi  wrote:
>
>> Hi Brian,
>>
>> There's been many interesting score languages and programs that
>> process text formats, some similarly to what you mentioned.  I think
>> overall though, the score format in Csound is best as-is, and other
>> layers of abstractions can be built on top of it.
>>
>> Also, you could use t-statements to modify tempo for processing score.
>> Using "t 0 120" sets the tempo to 120 bpm.  After that, score times
>> are in beats (actually, it's always in beats, with a default of 60
>> bpm).  You could use that to write scores such as .25 for sixteenths,
>> 1 for quarters, 4 for whole notes, etc.  You could also use something
>> like "t 0 480" if you want to use 4 for quarters, and 1 for
>> sixteenths, etc.  All of that is already built into Csound today.
>>
>> Thanks,
>> steven
>>
>> On Mon, Mar 5, 2012 at 3:36 PM, Brian Simmons  wrote:
>>> Hi everybody!
>>>
>>> I'm Brian Simmons, one of Dr.B's Csound students at Berklee, and I
>>> came up with an idea that might be worth looking into.
>>>
>>> I was thinking of a way to use note duration values based on tempo,
>>> like writing in quarter notes and eight notes in the p3 fields instead
>>> of using time values in seconds.
>>>
>>>
>>> These note duration would obviously have to be calculated based on a
>>> new bpm (beats per minute) argument (some kind of value converter?)
>>>
>>> I'm aware of the existence of macros, but I think having this tool be
>>> a little bit more integrated into the Csound environment would be a
>>> tremendous help for those that have even a very basic music theory
>>> background.
>>>
>>>
>>> This is the way I thought it would work:
>>>
>>> So if we have set a bpm of 120 beats per minute, the p3 fields would
>>> read and operate as following:
>>>
>>>
>>> Bpm = 120
>>>
>>> so then,  on your  p3:
>>>
>>> to make a quarter note, you type in "4" in p3, and the value converter
>>> should calculate   (1 * 60 / bpm)
>>>
>>> which would yield a result of a 0.5 second note.
>>>
>>>
>>> Other note values:
>>>
>>> half note        =       2        the converter calculates  (2 * 60 / bpm)
>>>
>>> whole note     =       1       the converter calculates  (4 * 60 / bpm)
>>>
>>> 8th note         =       8       the converter calculates  (0.5 * 60 / bpm)
>>>
>>> 16th note       =       16      the converter calculates  (0.25 * 60 / bpm)
>>>
>>> 32nd note     =        32      the converter calculates  (0.125 * 60 / bpm)
>>>
>>>
>>> Then we would only be missing dotted notes, triplets, quintuplets,
>>> ect; for these I was thinking you could use the value "4.1" for a
>>> dotted quarter note and the value converter would calculate  (1.5 * 60
>>> / bpm)
>>>
>>>
>>> double dotted quarter note  = 4.2        the converter calculates
>>> (1.75 * 60 / bpm)
>>>
>>> quarter note triplet               = 4.3        the converter
>>> calculates (2/3 * 60/ bpm)
>>>
>>> and so on, for the different time value alterations, (I can make a
>>> full list of them with calculations if this whole idea is worth
>>> pursuing).
>>>
>>>
>>>
>>> Maybe some way to have different tempos at different sections of the
>>> score would also be an interesting idea.
>>>
>>> If something like this were to be implemented, it would seriously cut
>>> down the time required to make very precise note durations on note
>>> list scores based on a  variable tempo.
>>>
>>>
>>> Thanks a lot for reading,
>>>
>>>
>>> ~Brian Simmons
>>>
>>>
>>> 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"
>

If it can be done with an optional switch at the head of the score, so that
90% of Csounders can safely ignore it, then fine -- do what you like! (Or
write a text processor that will convert your .txt score into a standard
.sco.)

Philosophically, I'd have to say that this proposal is a step backward, in
that it contains the built-in assumption that the rhythmic values used in
19th century European classical music are some sort of universal norm. They
ain't.

Even within the European classical tradition, note durations are not so
easily symbolized. How will this proposed codification notate staccati?
Septuplets? A dotted half tied to a sixteenth?

I haven't tried it, but I would think you could easily set up a system of
this sort using macros -- $Q for a quarter-note (#define Q # 1.0 #), $W for
a whole-note, and so on. If you need septuplets, create a $Qsept macro. Am I
missing a difficulty here, or would that be a piece of cake?

--
View this message in context: http://csound.1045644.n5.nabble.com/Note-duration-value-converter-idea-tp5537885p5538596.html
Sent from the Csound - General mailing list archive at Nabble.com.

On 05/03/2012 19:27, Jim Aikin wrote:
..
> Philosophically, I'd have to say that this proposal is a step
> backward, in that it contains the built-in assumption that the
> rhythmic values used in 19th century European classical music are
> some sort of universal norm. They ain't.

Not a problem confined to Csound of course; much the same criticism can 
be made of all DAW sequencers supporting staff notation, etc

>
> Even within the European classical tradition, note durations are not
> so easily symbolized. How will this proposed codification notate
> staccati? Septuplets? A dotted half tied to a sixteenth?
>

Note durations and articulations are typically the responsibility of the
instrument. The task of  a score language is not necessarily to spell
out every detail, but to provide any required parameters to the
instrument. Staccato might be just a flag argument in the score. A 
dotted half tied to a sixteenth is usually an idiom particular to staff 
notation; no reason it can't just be specified as a+b in a score 
language. A more interesting issue is slurs and general legato idioms 
(but note that SCOT does have a solution for this, and supports the 
"nextp" idiom.


> I haven't tried it, but I would think you could easily set up a
> system of this sort using macros -- $Q for a quarter-note (#define Q
> # 1.0 #), $W for a whole-note, and so on. If you need septuplets,
> create a $Qsept macro. Am I missing a difficulty here, or would that
> be a piece of cake?
>


Your points are really why it would be wrong to try to revise the Csound
score language as such - there are just too many differences of need in
the community. Instead, by keeping the underlying score language as
generic as possible, we can posit any number of variant score languages
that generate compatible Csound score output, and the composer may use
several of them in the course of creating a piece.

A critical aspect of the Csound score language is the fact that you are
not required to write all events in ascending time order. Using the
Section instruction, you can. for example, write all the notes for S,
followed by all the notes for A, then T and B and so on; Csound will
then kindly sort them all into final note order for you. You can include
dynamic tempo changes (accelerandos etc), and you can compose phrase by
phrase if you have to. So it would be well within the scope of the
current language for you to define a phrase as a section, implementing
whatever note division you want, such as a legato septuplet. Passing the 
"Le Marteau" test might well be a reasonable measure of a score language 
(I still remember the (2/3)/2 bar towards the end!).

And it is perfectly possible to write in an "conventional" 19th Century 
way and still be contemporary; with so many contemporary idioms around 
at least one of them is bound to fit.  Of course the degree of precision 
required may be anathema to some composers... :-).


Richard Dobson

I think it's a good idea.

It seems like this is addressing the idea of writing music in Csound
using an alternate system of score events that more closely resembles
musical notation. I think you might be able to achieve something
similar using Cybil or another Csound score preprocessor.

I'd think you would really just need to sit and think about how you
envision building the system with your supposed "ideal input" as you
have described and what you perceive as the "ideal output". Once you
answer that question I'd imagine you could make something neat like
Steven's p3 value reassignment UDO or even some higher level graphical
application that displays the musical time from Csound scores and
transparently converts to and from MIDI. I'm not sure how I would
approach this was tasked with solving this issue, it would take a lot
of thought and pacing back and forth but the result could be quite
interesting and practical.


-David

On Mon, Mar 5, 2012 at 9:36 AM, Brian Simmons  wrote:
> Hi everybody!
>
> I'm Brian Simmons, one of Dr.B's Csound students at Berklee, and I
> came up with an idea that might be worth looking into.
>
> I was thinking of a way to use note duration values based on tempo,
> like writing in quarter notes and eight notes in the p3 fields instead
> of using time values in seconds.
>
>
> These note duration would obviously have to be calculated based on a
> new bpm (beats per minute) argument (some kind of value converter?)
>
> I'm aware of the existence of macros, but I think having this tool be
> a little bit more integrated into the Csound environment would be a
> tremendous help for those that have even a very basic music theory
> background.
>
>
> This is the way I thought it would work:
>
> So if we have set a bpm of 120 beats per minute, the p3 fields would
> read and operate as following:
>
>
> Bpm = 120
>
> so then,  on your  p3:
>
> to make a quarter note, you type in "4" in p3, and the value converter
> should calculate   (1 * 60 / bpm)
>
> which would yield a result of a 0.5 second note.
>
>
> Other note values:
>
> half note        =       2        the converter calculates  (2 * 60 / bpm)
>
> whole note     =       1       the converter calculates  (4 * 60 / bpm)
>
> 8th note         =       8       the converter calculates  (0.5 * 60 / bpm)
>
> 16th note       =       16      the converter calculates  (0.25 * 60 / bpm)
>
> 32nd note     =        32      the converter calculates  (0.125 * 60 / bpm)
>
>
> Then we would only be missing dotted notes, triplets, quintuplets,
> ect; for these I was thinking you could use the value "4.1" for a
> dotted quarter note and the value converter would calculate  (1.5 * 60
> / bpm)
>
>
> double dotted quarter note  = 4.2        the converter calculates
> (1.75 * 60 / bpm)
>
> quarter note triplet               = 4.3        the converter
> calculates (2/3 * 60/ bpm)
>
> and so on, for the different time value alterations, (I can make a
> full list of them with calculations if this whole idea is worth
> pursuing).
>
>
>
> Maybe some way to have different tempos at different sections of the
> score would also be an interesting idea.
>
> If something like this were to be implemented, it would seriously cut
> down the time required to make very precise note durations on note
> list scores based on a  variable tempo.
>
>
> Thanks a lot for reading,
>
>
> ~Brian Simmons
>
>
> 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"
>

Thank you Michael for your view on this.  I think that it is very important to get it right, but that it is very important to support "musical" thinking in Csound at every level - especially
in terms of bars, beats, measures, frames, etc...  Have you all tried Brian Baughn's macro system.   Some nice things in here to consider:


On Mar 5, 2012, at 11:11 AM, Michael Gogins wrote:

> I think that as long as there is as usual complete backwards
> compatibility, then denominating times in musical units is a good
> idea. But of course it should be well thought out. I think this would
> have to come with opcodes in the sco language for meter and tuplet as
> well as tempo. Perhaps time would be bar:beat and duration would be
> beats:meter or something like that.
> 
> I think this is a very complex issue and needs careful consideration.
> Let's have a look at MusicXML, MIDI, and commercial software to see
> how they do it.
> 
> Regards,
> Mike
> 
> On Mon, Mar 5, 2012 at 10:57 AM, Dr. Richard Boulanger
>  wrote:
>> But don't you think we need a value converter.  Not having one is like saying Freq in Hz is best and we don't need cpspch().  Linear amp is fine so we don't need 0dbfs or ampdb.  And we  certainly don't need any MIDI converters because it lacks precision and resolution?
>> 
>> Adding a sense of musical time to Csound is long overdue.
>> 
>> Check out Maple7 by my student Brian Baughn for a good example of a completely worked out macro solution.  Still...  We really need this and better advance and Tempo support...  Like over sections.
>> 
>> -dB
>> 
>> Sent from my iPhone.
>> 
>> On Mar 5, 2012, at 10:42 AM, Steven Yi  wrote:
>> 
>>> Hi Brian,
>>> 
>>> There's been many interesting score languages and programs that
>>> process text formats, some similarly to what you mentioned.  I think
>>> overall though, the score format in Csound is best as-is, and other
>>> layers of abstractions can be built on top of it.
>>> 
>>> Also, you could use t-statements to modify tempo for processing score.
>>> Using "t 0 120" sets the tempo to 120 bpm.  After that, score times
>>> are in beats (actually, it's always in beats, with a default of 60
>>> bpm).  You could use that to write scores such as .25 for sixteenths,
>>> 1 for quarters, 4 for whole notes, etc.  You could also use something
>>> like "t 0 480" if you want to use 4 for quarters, and 1 for
>>> sixteenths, etc.  All of that is already built into Csound today.
>>> 
>>> Thanks,
>>> steven
>>> 
>>> On Mon, Mar 5, 2012 at 3:36 PM, Brian Simmons  wrote:
>>>> Hi everybody!
>>>> 
>>>> I'm Brian Simmons, one of Dr.B's Csound students at Berklee, and I
>>>> came up with an idea that might be worth looking into.
>>>> 
>>>> I was thinking of a way to use note duration values based on tempo,
>>>> like writing in quarter notes and eight notes in the p3 fields instead
>>>> of using time values in seconds.
>>>> 
>>>> 
>>>> These note duration would obviously have to be calculated based on a
>>>> new bpm (beats per minute) argument (some kind of value converter?)
>>>> 
>>>> I'm aware of the existence of macros, but I think having this tool be
>>>> a little bit more integrated into the Csound environment would be a
>>>> tremendous help for those that have even a very basic music theory
>>>> background.
>>>> 
>>>> 
>>>> This is the way I thought it would work:
>>>> 
>>>> So if we have set a bpm of 120 beats per minute, the p3 fields would
>>>> read and operate as following:
>>>> 
>>>> 
>>>> Bpm = 120
>>>> 
>>>> so then,  on your  p3:
>>>> 
>>>> to make a quarter note, you type in "4" in p3, and the value converter
>>>> should calculate   (1 * 60 / bpm)
>>>> 
>>>> which would yield a result of a 0.5 second note.
>>>> 
>>>> 
>>>> Other note values:
>>>> 
>>>> half note        =       2        the converter calculates  (2 * 60 / bpm)
>>>> 
>>>> whole note     =       1       the converter calculates  (4 * 60 / bpm)
>>>> 
>>>> 8th note         =       8       the converter calculates  (0.5 * 60 / bpm)
>>>> 
>>>> 16th note       =       16      the converter calculates  (0.25 * 60 / bpm)
>>>> 
>>>> 32nd note     =        32      the converter calculates  (0.125 * 60 / bpm)
>>>> 
>>>> 
>>>> Then we would only be missing dotted notes, triplets, quintuplets,
>>>> ect; for these I was thinking you could use the value "4.1" for a
>>>> dotted quarter note and the value converter would calculate  (1.5 * 60
>>>> / bpm)
>>>> 
>>>> 
>>>> double dotted quarter note  = 4.2        the converter calculates
>>>> (1.75 * 60 / bpm)
>>>> 
>>>> quarter note triplet               = 4.3        the converter
>>>> calculates (2/3 * 60/ bpm)
>>>> 
>>>> and so on, for the different time value alterations, (I can make a
>>>> full list of them with calculations if this whole idea is worth
>>>> pursuing).
>>>> 
>>>> 
>>>> 
>>>> Maybe some way to have different tempos at different sections of the
>>>> score would also be an interesting idea.
>>>> 
>>>> If something like this were to be implemented, it would seriously cut
>>>> down the time required to make very precise note durations on note
>>>> list scores based on a  variable tempo.
>>>> 
>>>> 
>>>> Thanks a lot for reading,
>>>> 
>>>> 
>>>> ~Brian Simmons
>>>> 
>>>> 
>>>> 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
> 
> 
> 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"
> 

On 06/03/2012 07:56, Dr. Richard Boulanger wrote:
> I am not proposing that we resurrect Scot - a grad student project which
> was abandoned the semester after it was turned in...
>

At the very least it may be a source of ideas. These days we would 
define a language via yacc/lex; but defining the language needs a lot of 
discussion, testing and iteration. Either one programmer has a blitz and 
publishes some fully-formed de facto product (in which case you may get 
something quickly, but with all the maintenance risks associated with a 
solo effort), or it is (like Csound 5 itself) the result of communal 
iterative discussion and development.


> I am absolutely not proposing that we create some new and elaborate
> score language.
>
> I am proposing that we add a value converter (or set of them) that would
> allow time to be expressed in terms of bars, beats, measures...
>
> is it possible? or impossible? I am hoping for a decent cheeseburger
> here, not proposing that we open a fast-food restaurant chain.
> *___________________________________*


My suggestion is that for development purposes we support a new file 
extension such as .seq, and use that for incremental development of an 
extended mensural score language (even if to begin with it just adds a 
few things to the current score language). I don't discount the 
possibility of maintaining the distinction between .sco and .seq for ever.

HMSL/JMSL may be useful references for any new notation. We are not 
simply converting a number: 
"measure/measure-division/beat/subdivision/unit" is clearly a hierarchy 
which to be at all readable will need to be expressed very clearly. 
Quite possibly this will not be the case if we simply embed a "value" in 
the p2 and p3 slots of an i statement. It may well be that for both 
clarity and ease of future development something other than a modified i 
statement will be needed. A note event may demand more than one line of 
text. Composers may immediately want a new means of expressing chords, 
parallel voices with individual metrical structures, etc.

Richard Dobson

On the whole, I'm in favor of something like this.  But on the 
other hand, I'm currently working on a piece that uses a uniform 
measure duration (3 sec's), with measures subdivided into 2, 3 
or 5 beats, and each of these beats subdivided into 'duplets', 
'triplets', or 'pentuplets'.  Calculating the exact durations 
for use in the score was done with a spreadsheet.  Then I simply 
choose what is appropriate for the type of measure, type of beat 
division, and placement within the beat.  This could probably be 
done more easily using Python, but I guess I'm just too much a 
'hands-on' control freak to bother.  Anyway, for more 'standard' 
music, I like this suggestion, as long as it;ll still let me do 
weird stuff, too.
Bob

On 13:59, Brian Simmons wrote:
> Hi everybody!
>
> I'm Brian Simmons, one of Dr.B's Csound students at Berklee, and I
> came up with an idea that might be worth looking into.
>
> I was thinking of a way to use note duration values based on tempo,
> like writing in quarter notes and eight notes in the p3 fields instead
> of using time values in seconds.
>
>
> These note duration would obviously have to be calculated based on a
> new bpm (beats per minute) argument (some kind of value converter?)
>
> I'm aware of the existence of macros, but I think having this tool be
> a little bit more integrated into the Csound environment would be a
> tremendous help for those that have even a very basic music theory
> background.
>
>
> This is the way I thought it would work:
>
> So if we have set a bpm of 120 beats per minute, the p3 fields would
> read and operate as following:
>
>
> Bpm =20
>
> so then,  on your  p3:
>
> to make a quarter note, you type in "4" in p3, and the value converter
> should calculate   (1 * 60 / bpm)
>
> which would yield a result of a 0.5 second note.
>
>
> Other note values:
>
> half note        =     2        the converter calculates  (2 * 60 / bpm)
>
> whole note     =     1       the converter calculates  (4 * 60 / bpm)
>
> 8th note         =     8       the converter calculates  (0.5 * 60 / bpm)
>
> 16th note       =     16      the converter calculates  (0.25 * 60 / bpm)
>
> 32nd note     =      32      the converter calculates  (0.125 * 60 / bpm)
>
>
> Then we would only be missing dotted notes, triplets, quintuplets,
> ect; for these I was thinking you could use the value "4.1" for a
> dotted quarter note and the value converter would calculate  (1.5 * 60
> / bpm)
>
>
> double dotted quarter note  =.2        the converter calculates
> (1.75 * 60 / bpm)
>
> quarter note triplet               =.3        the converter
> calculates (2/3 * 60/ bpm)
>
> and so on, for the different time value alterations, (I can make a
> full list of them with calculations if this whole idea is worth
> pursuing).
>
>
>
> Maybe some way to have different tempos at different sections of the
> score would also be an interesting idea.
>
> If something like this were to be implemented, it would seriously cut
> down the time required to make very precise note durations on note
> list scores based on a  variable tempo.
>
>
> Thanks a lot for reading,
>
>
> ~Brian Simmons
>

> Why are all of you making this "simple" request into such a "huge" project
that absolutely no one (in their right mind) 
> will have time or would want to undertake it. Of course it makes no sense
> to create a "sequencer" when we have
> so many - including Blue - which... by the way... even though Steven
> started this all off on the wrong track... I believe...
> supports bars, beats, measure, MM, etc...
> 
> I am asking for a simple set of value converters - not a new score
> language.

It might be pretty easy to create an opcode that would convert "coded" p3
numbers into a new, rhythm-based value for p3, because an instrument can
already alter its own p3. But that would have no effect on p2, which I'm
pretty sure would still have to be entered as raw beats. If it weren't, the
score couldn't be sorted properly. So it seems to me that what you're
envisioning, Richard, would, if implemented, create a situation where p2 and
p3 would, as displayed in the score, be radically different in concept.

As a result, the + notation could not be used in p2, because it would be
meaningless. And the composer would then have the added brain-burden of
interpreting two entirely different types of data in the score.

In addition, if this concept were implemented as an opcode, the score values
for p3 could _only_ be numerical. You couldn't enter, say, 8t as a p3 to
produce an eighth-note triplet, because the current score sorting mechanism
would choke on that. You could, however, put coded text in p4, to be
converted into a p3 in the instrument.

But is there really an advantage to be gained by entering 8 to produce an
eighth-note rather than .5? I don't quite see it.

The other problem -- and I'm talking through my hat, because I really have
no idea what happens under the hood in Csound -- is that the type of opcode
you're envisioning -- let's call it secdur -- would need some way to get at
the current tempo of the score, as defined by the t statement. Maybe there's
a way to get this to happen, but the point is, if you feed a 4 to secdur
because you want a quarter-note, secdur would have to produce a p3 of 0.5
second if the current tempo (as defined by the t statement) is 120 bpm, and
a p3 of 1.0 second if the current tempo is 60 bpm. Is there a way to pass
the value of the t statement (which may be changing from moment to moment)
from the score into the orchestra? That's a question that I'm not equipped
to answer, but I'm pretty sure it's a relevant question. So I'm guessing
that your request for a simple durational value converter may not be quite
as simple as you're hoping.

> "How can I make loops, sounds, phrases, and time them in a way that I can
> just drop them 
> into my ProTools Sessions or Live Remixes?"

With a t statement in the score, perhaps? Is there any reason why this
wouldn't work? I've never done it, but I think that ought to work. And if
you happen to need to calibrate an LFO to the tempo of the Live project, the
venerable formula ms-per-beat = 60000 / bpm is not difficult to deploy.

--
View this message in context: http://csound.1045644.n5.nabble.com/Note-duration-value-converter-idea-tp5537885p5549671.html
Sent from the Csound - General mailing list archive at Nabble.com.

Hi Dr. B,

To note: this conversation started as a technical disagreement for me,
and I laid out complexities that would arise from the proposal and why
I do not think it is "simple". Please engage with the technical side
of this and don't bring up rhetoric about not being musical.  I'm a
composer and a musician every bit as much as I am a programmer, and
ask you respect that as much as I respect you and your student's
position. I believe I have been respectful of you and others
throughout, so bringing in discussion about the community or making
this personal doesn't really move the dialogue forward, IMO, and ask
you bring back the conversation to the technical side.

And also to clarify, if anyone, either you or your students or others
have taken any of this as an attack on you or them, rather than a
disagreement on the implementation of an idea, then you have my
apologies.

I don't think anyone has suggested that working with values like
quarters, eighths, etc. is a bad idea, far from it.  I think I've
mentioned that a couple times now, so please don't misinterpret the
disagreement as being against using musical values. I use measured
time in local time spaces often when composing, so that wouldn't make
sense for me to argue against that. What I have disagreed with is that
this should be in Csound itself, and I have laid out technical reasons
as to why this is not just a simple request.  Unfortunately, I must
not have explained all of the technical difficulties clearly, so let
me try again here.

* The examples you give of converters are all things in the orchestra.
 Your proposal requires modification to the score format, and
consequently its parser.  Therefore, comparing cpspch and amdpbfs to
your proposal is and apples and oranges comparison.

* The UDO example I gave is more appropriate to discuss, as it is a
more fair comparison.  It is a value converter like cpspch.  Even with
that, we saw the incompatibilities with existing score notation using
"+" operator.

* To implement the proposed idea, which is to modify how the score is
interpreted, introduces a non-generic solution to a musical problem.
This is one of the big issues I have, especially since this musical
problem has been dealt with over the years by the introduction of
secondary tools.  The beauty of what is already in csound is that it
has been able to support so many different secondary tools (nGen,
score11, cmask, custom code by composer, etc.), all with very
different notions of time.  So there are already solutions to this
musical problem, just not the one proposed.

* You have brought up macros as already a solution to this problem as
well.  In Csound, since the score has no language really, that's
probably the only in-Csound solution at the moment.  However, it is a
generic solution, and users can use it to define whatever they like
for time values, and it would work with + and other things.

* I haven't mentioned this, but I really do like John's solution of
csbeats, and more particularly, the ability to call secondary score
processors just by stating what to use within the CSD itself.  I'd
ask, would this not work for you and your students?  You'd be able to
use a score processor but wouldn't have to do much more than:


...


so everything is within a single file, you could use CsoundQT, etc.
Rather than try to modify Csound, we leverage what is already there,
you and your students get exactly what you want, and we don't have to
get into all the hairy issues involved. We also know that score
processors as a solution works, as it's been done for years.

In addition, you'd be able to use that kind of score notation then
from something like blue, which could call csbeats (or other program)
to interpet that score, that'd get transformed into standard csound
SCO notation, then continue processing.  Beyond me, others can then
leverage an external score processor as well. To me, this is just so
much more elegant a solution, and introduces no changes to Csound's
processing.  It's also a much longer-term solution, and keeps Csound's
complexity down.

===

Hopefully, I have stated my argument a bit more clearly.  To
reiterate, I actually do think this is more than just a simple
request, and that there are a lot of devil in the details here.

Thanks,
steven


On Fri, Mar 9, 2012 at 3:48 AM, Dr. Richard Boulanger
 wrote:
> Why are all of you making this "simple" request into such a "huge" project
> that absolutely no one (in their right mind)
> will have time or would want to undertake it. Of course it makes no sense to
> create a "sequencer" when we have
> so many - including Blue - which... by the way... even though Steven started
> this all off on the wrong track... I believe...
> supports bars, beats, measure, MM, etc...
>
> I am asking for a simple set of value converters - not a new score language.
>
> Is it too difficult to add a simple set of durational value converters
> (comparable to cpsmidi() cpspch() ampdb() etc...
> (which by the way... are all flawed.. and all biased... and all quite
> limited...)
>
> Is it too difficult to add a simple set of durational value converters...
> ( like amppdb() which is as blind to the many issues associated with
> loudness and perception of loudness and psychoacoustics, and timbre,
> and fletcher-munson curves and equal-power issues, and spatial issues, and..
> worst of all - to samples out of range issue .... in fact,
> one could say that ampdb() is pretty dumb, but... as value converters go...
> it has been quite convenient... )
>
> Is it too difficult to add a simple set of durational value converters such
> as...  secdur()
> which would convert numbers written in some shorthand that relates to
> traditional note durations into seconds.
>
> guess so...
>
> -dB
>
> PS.... please note that this feature has not been requested by a lowly
> student that doesn't know any better and who needs to be educated and
> enlightened in value conversion and the beauties of thinking in clock time
> rather than musical time.... (trust me... they get there and beyond in all
> my classes).... This "basic" and "obvious" missing "essential" in fact, has
> been requested again and again over the past 26 years... again and again....
> by "music" students... who are brilliant beyond their years and dedicated
> beyond reason).  {"How do you sync a Csound LFO with an LFO or Delay from
> another "music" program?"  "How can I make loops, sounds, phrases, and time
> them in a way that I can just drop them
> into my ProTools Sessions or Live Remixes?"}  These brilliant and dedicated
> "musicians" have been composing, recording, producing, performing "music"
> with computers
> since they were 8 years old and when I finally introduce them to the
> "world's most powerful computer "music" program and synthesizer - Csound ...
> they come to it... as "musicians" not programmers or mathematicians.  I
> trust them. In fact, there is nothing more valuable to a developer - than a
> beginner who is hungry to learn and I treasure this resource
> and all that they bring.  And so... this year... a very dedicated musician
> came to me and outlined his request/suggestion/issue.... I suggested that he
> write you all...
>
> I could have told him - here a UDO that I use.  Here's some Macros that a
> former student developed that really do the trick.  Here's John ffitch's
> chapter in the Csound Book.
>
> Rather, I told all my students that this is an amazing community. One that
> listens to students.  And that many ideas that my former students had
> proposed in the past have turned
> into opcodes....  This community wants to welcome you and celebrate you and
> your music and your ideas....
>
> And what....  instead I am getting slammed and so are my students... and so
> are all students...  because we want Csound to be "everything" or because we
> should
> just use Garage Band is we want "beats".... what?
>
> I use food metaphors in my teaching... so forgive me....
>
> I told my students that his was a hot-fudge sundae and when they looked...
> there was no hot fudge... and in fact... they were asked to leave the diner
> for even asking about
> hot-fudge sundaes...
>
> Computer Music Software - where's the music?
>
>
>
>
> ___________________________________
>
> Dr. Richard Boulanger, Ph.D.
>
> Professor of Electronic Production and Design
> Professional Writing and Music Technology Division
> Berklee College of Music
> 1140 Boylston Street
> Boston, MA 02215-3693
>
> 617-747-2485 (office)
> 774-488-9166 (cell)
>
> rboulanger@berklee.edu
> http://csounds.com/boulanger
> ____________________________________
>
> http://csounds.com
> http://csoundforlive.com
> ____________________________________
>
> http://csounds.com/mathews
> ____________________________________
>
> On Mar 6, 2012, at 4:30 AM, Richard Dobson wrote:
>
> On 06/03/2012 07:56, Dr. Richard Boulanger wrote:
>
> I am not proposing that we resurrect Scot - a grad student project which
>
> was abandoned the semester after it was turned in...
>
>
>
> At the very least it may be a source of ideas. These days we would define a
> language via yacc/lex; but defining the language needs a lot of discussion,
> testing and iteration. Either one programmer has a blitz and publishes some
> fully-formed de facto product (in which case you may get something quickly,
> but with all the maintenance risks associated with a solo effort), or it is
> (like Csound 5 itself) the result of communal iterative discussion and
> development.
>
>
> I am absolutely not proposing that we create some new and elaborate
>
> score language.
>
>
> I am proposing that we add a value converter (or set of them) that would
>
> allow time to be expressed in terms of bars, beats, measures...
>
>
> is it possible? or impossible? I am hoping for a decent cheeseburger
>
> here, not proposing that we open a fast-food restaurant chain.
>
> *___________________________________*
>
>
>
> My suggestion is that for development purposes we support a new file
> extension such as .seq, and use that for incremental development of an
> extended mensural score language (even if to begin with it just adds a few
> things to the current score language). I don't discount the possibility of
> maintaining the distinction between .sco and .seq for ever.
>
> HMSL/JMSL may be useful references for any new notation. We are not simply
> converting a number: "measure/measure-division/beat/subdivision/unit" is
> clearly a hierarchy which to be at all readable will need to be expressed
> very clearly. Quite possibly this will not be the case if we simply embed a
> "value" in the p2 and p3 slots of an i statement. It may well be that for
> both clarity and ease of future development something other than a modified
> i statement will be needed. A note event may demand more than one line of
> text. Composers may immediately want a new means of expressing chords,
> parallel voices with individual metrical structures, etc.
>
> Richard Dobson
>
>
>
> 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"
>
>

Difficult to know which message is most appropriate to reply to, so 
somewhat arbitrarily I have chosen this one.

On 09/03/2012 03:48, Dr. Richard Boulanger wrote:
..
>
> I am asking for a simple set of value converters - not a new score language.
>

But it can't be a simple value converter, because the "unit" is not a 
value, it is a composite of several - measure, division, beat, 
subdivision, unit, etc. Csound already expresses itself in beats, it 
just so happens that relatively few people bother to use the t directive 
for tempo, and the default is t=60, so the values equate directly to 
seconds. If you want 4/4 at mm 120 (or mm180 for the clubs), just set 
t=180 and block out your score lines measure by measure; each start time 
will be a precise multiple or fraction of  that beat. You can even add 
comments, counting measures - example already exist which do that. The 
score language does ~not~ require times to be specified in seconds. With 
t=180 a p3 value of 0.75 is a dotted eight-note at that tempo. To render 
a score faster or slower, you just add/change the t statement at the 
appropriate place and run it.


> Is it too difficult to add a simple set of durational value converters
> (comparable to cpsmidi() cpspch() ampdb() etc...
> (which by the way... are all flawed.. and all biased... and all quite
> limited...)
>

They are not meant to be anything else. They are 'true" (i.e. simple) 
numeric converters. MIDI converts to standard equal temperament, for 
example.



> Is it too difficult to add a simple set of durational value converters...
> ( like amppdb() which is as blind to the many issues associated with
> loudness and perception of loudness and psychoacoustics, and timbre,
> and fletcher-munson curves and equal-power issues, and spatial issues,
> and.. worst of all - to samples out of range issue .... in fact,
> one could say that ampdb() is pretty dumb, but... as value converters
> go... it has been quite convenient... )


I think this considerably over-eggs the argument. Literally all the db 
opcodes do is convert between linear  values (implicitly amplitude) and 
decibel values, e.g using the 20*log10(amp) formula or its inverse, 
either referenced to 0dbfs or not. Nothing whatsoever to do with 
psycho-acoustic things. I dread to imagine what the notation would look 
like that specified a dB conversion as either A-weighted or B-weighted 
(which is frequency-dependent anyway).

>
> Is it too difficult to add a simple set of durational value converters
> such as... secdur()
> which would convert numbers written in some shorthand that relates to
> traditional note durations into seconds.
>

See above - use the tempo directive and you can express durations as 
multiples or fractions of a beat.

Now, if that is not enough, the discussions have to start.

There has never been any question as to whether representing musical 
time in beats etc is reasonable  - of course it is. The question is 
about the best way do to it without scrambling what we already have. Or 
in other words, defining exactly and sufficiently what that "some 
shorthand" comprises.

It is a multi-dimensional issue. As I say, we already can define time 
values as raw beats at a nominated tempo. What you appear to be asking 
for is a ~symbolic~ notation that presumably references standard staff 
notation - a unit for a bar/meausre, a time signature, and then units 
such as triplets, septuplets and sixteenth notes. Hopefully in a way 
that can to some degree support arbitary divisions such as a group of 11 
in the time of 7 somethings. Or, do we confine it to simple 4/4 bars 
with sixteenth notes?

A key aspect of all this which does not at all apply to the existing 
plain beat notation is that, just as in staff notation, ~it is possible 
to make a mistake~ - specify  a 4/4 time signature and then write five 
quarter notes in a measure. If you eschew the measure and "just" write 
some symbol that combines a nominal unit (quarter notes?) which itself 
must be referenced to some tempo, and then just stream a list of 
fractions or multiples of that unit, the result will, I suggest, be no 
more expressive or readable that what we already have. Almost by 
definition, you want a notation that corresponds as closely as possible 
to staff notation, so that you and your students can read and navigate 
it quickly.  That involves not a value converter but grammar, syntax and 
error correction.

Even a "simple" division such as triplets can potentially cause rounding 
problems, simply because arithmetic using such numbers can lead to the 
classic 10/3 = 0.333* issue - it doesn't ~quite~ add up, so care has to 
be taken to ensure the next beat is actually correctly times; all also 
affected as we know by the resolution allowed by the value of ksamps.

Currently, score beat times (in a section) start from 0. Conversely in 
staff notation the beats in each measure count from 1, so some notation 
has to be incorporated to define and count measures, so start times can 
run as a cycle of 1-2-3-4-1-2-3-4. Already  we have to decide if the 
responsibility for correctness lies with the composer or with the software.

There is also the point to be made that Csound as constituted is a 
"literal" languuge - it does indeed specify  duration in beats or 
fractions thereof, and those literal durations reach the isntrument 
which deals with it as it is desgined to do. However, staff notation 
note values are much more symbolic that they are literal - a quarter 
note on a violin can well be the full length; but if detache its true 
duration is rather less. So you either have to assume that you continue 
to write quarter notes and the instrument has to know to make it 
pizzicato, or you change the notation to make it a sixteenth note or 
whatever. Conversely, you will presumably want to preserve all the 
existing methods of specifying ties and general legato (OK, club music 
has none of either, but we do not limit ourselves to that!), so that 
whole areas of grammar and syntax has to be supported in a way that does 
not conflict with the existing system. Can we mix measure/beat notation 
with standard notation?

If we just deal with durations, and leave p2 handling as it is, what 
woudl your preferred notation be. Say a dotted 1/8 note: currently we 
woul write 0.75. Do you want "3*(1/16)", "1/8 + 1/16", or perhaps 
"1/8."? An alternative is to define unit directives so you write:
u 8  ; unit is an eight note
i1 1 1. ; dotted  note, "beat 1"

Then, if we write on the next line
i1 + .
what should that mean? A dotted note starting on beat 1.5, or starting 
on the final sixteenth of the previous note, or starting on beat 2? So 
to clarify we might need to write:

m4      ; 4 beats per measure
b4      ; beat unit is quarter note, so this is 4/4

u8      ; current dur unit is eighth note
i1 1 1. ; dotted  eighth-note, "beat 1"
i1 + .  ; dotted eighth-note,  "beat 2"
i1 + .
i1 + .
i1 1 .  ; this is beat 1 of measure 2; if we had written:
i1 + .  ; we would have to report an error, or at least a warning.

How would we notate a section starting at measure 2, 3 or whatever?

It is easy to see how this rapidly leads to just the sorts of language 
idioms and notations of the score languages already discussed.

In short, even a "simple" scheme is a scheme nevertheless, probably 
impossible to be kept simple, and can be got right or wrong, be flexible 
or inflexible, be extensible or fixed for all time. And may be 
impossible to integrate with the existing score language.

However we go about this, I still say that the only ~safe~ way to 
develop such a thing is via a completely independent system (forked from 
the current score handler if necessary) which outputs raw tims and 
durations that the orchestra already deals with. That is to say, a new 
score language. Examples already exist and have been mentioned here before.

Richard Dobson

> * I haven't mentioned this, but I really do like John's solution of
> csbeats, and more particularly, the ability to call secondary score
> processors just by stating what to use within the CSD itself.  I'd
> ask, would this not work for you and your students?  You'd be able to
> use a score processor but wouldn't have to do much more than:
>
> 
> ...
> 
>
> so everything is within a single file, you could use CsoundQT, etc.
> Rather than try to modify Csound, we leverage what is already there,
> you and your students get exactly what you want, and we don't have to
> get into all the hairy issues involved. We also know that score
> processors as a solution works, as it's been done for years.
>
> In addition, you'd be able to use that kind of score notation then
> from something like blue, which could call csbeats (or other program)
> to interpet that score, that'd get transformed into standard csound
> SCO notation, then continue processing.  Beyond me, others can then
> leverage an external score processor as well. To me, this is just so
> much more elegant a solution, and introduces no changes to Csound's
> processing.  It's also a much longer-term solution, and keeps Csound's
> complexity down.

This sums it up to me.

+1

Stef

> Given all my years of teaching Csound to now thousands of "musicians", I
can assure
> you that for some, there would be a "real" advantage to using 8 for an
> eighth note...
> and A4 for 440Hz.
> 
> I would like Csound to support and attract and "work" for everyone... and
> as they get
> in to it... they can discover all the more abstract and beautiful openness
> that is there.

I agree that asking all students to grasp every aspect of a complex system
at one fell swoop is not likely to be good pedagogy.

As I said earlier in this thread, I think having an alternative system for
inputting rhythm values is fine, as long as 90% of Csound composers are free
to ignore it -- because it _does_ impose some rather serious musical
limitations. And I'm still wondering how one would get the current,
momentary value of the tempo (as defined by the t statement) out of the
score and into the orchestra at the start of each new note. Maybe this could
be stored in a (usually invisible) p0, where the instrument instance could
access it if needed.

> By the way Jim... I just got your book from Amazon and as I jump around
> and read
> from here and there, I am loving it.  
> It's a great size.  It's gote great scope.  And it's a great read. 
> Several of my
> students (the ones who wish Csound had musical value converters in fact!) 
> got
> their copies before I did and are reading and loving it too.

I'm glad to hear that people are finding it useful. As I get older, I find
that I'm more inclined to want to spend time on a project if I can see that
it might be useful to other people. If I can't see the utility, I just about
won't bother anymore.

I was a little concerned that the Floss Manual would make the book
redundant, but my publisher encouraged me to take the view that, just as
there's room in the world for more than one Pro Tools book, there's room in
the world for more than one introduction to Csound.

I only wish they had made the type a little smaller in order to make the
margins a little wider. Personally, I like scribbling in the margin, and the
book is laid out badly for that purpose.

--JA

--
View this message in context: http://csound.1045644.n5.nabble.com/Note-duration-value-converter-idea-tp5537885p5551863.html
Sent from the Csound - General mailing list archive at Nabble.com.

I bought your book, and I think it will be useful. I think it will be
handy for musicians who know a little bit about synthesizers or DSP
and want to get up to speed with Csound. In that sense it fills gap in
the continuum, where the FLOSS manual is sort of in the middle.

Of course Csound will always have complete backwards compatibility, so
introducing new translators for musical semantics will not break that.
I think the question is whether inventing this at the same time as we
are getting started rewriting the engine of Csound is the best use of
developer time. But then again, maybe it's a good time to be thinking
about this.

Perhaps the best approach will be to introduce another layer of
abstraction between the score file and the engine, where the current
score parser is just one option, and other score parsers can also
used.

Regards,
Mike

On Fri, Mar 9, 2012 at 5:22 PM, Jim Aikin  wrote:
>> Given all my years of teaching Csound to now thousands of "musicians", I
> can assure
>> you that for some, there would be a "real" advantage to using 8 for an
>> eighth note...
>> and A4 for 440Hz.
>>
>> I would like Csound to support and attract and "work" for everyone... and
>> as they get
>> in to it... they can discover all the more abstract and beautiful openness
>> that is there.
>
> I agree that asking all students to grasp every aspect of a complex system
> at one fell swoop is not likely to be good pedagogy.
>
> As I said earlier in this thread, I think having an alternative system for
> inputting rhythm values is fine, as long as 90% of Csound composers are free
> to ignore it -- because it _does_ impose some rather serious musical
> limitations. And I'm still wondering how one would get the current,
> momentary value of the tempo (as defined by the t statement) out of the
> score and into the orchestra at the start of each new note. Maybe this could
> be stored in a (usually invisible) p0, where the instrument instance could
> access it if needed.
>
>> By the way Jim... I just got your book from Amazon and as I jump around
>> and read
>> from here and there, I am loving it.
>> It's a great size.  It's gote great scope.  And it's a great read.
>> Several of my
>> students (the ones who wish Csound had musical value converters in fact!)
>> got
>> their copies before I did and are reading and loving it too.
>
> I'm glad to hear that people are finding it useful. As I get older, I find
> that I'm more inclined to want to spend time on a project if I can see that
> it might be useful to other people. If I can't see the utility, I just about
> won't bother anymore.
>
> I was a little concerned that the Floss Manual would make the book
> redundant, but my publisher encouraged me to take the view that, just as
> there's room in the world for more than one Pro Tools book, there's room in
> the world for more than one introduction to Csound.
>
> I only wish they had made the type a little smaller in order to make the
> margins a little wider. Personally, I like scribbling in the margin, and the
> book is laid out badly for that purpose.
>
> --JA
>
> --
> View this message in context: http://csound.1045644.n5.nabble.com/Note-duration-value-converter-idea-tp5537885p5551863.html
> Sent from the Csound - General mailing list archive at Nabble.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"
>



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

Am 09.03.2012 23:22, schrieb Jim Aikin:
> I was a little concerned that the Floss Manual would make the book
> redundant, but my publisher encouraged me to take the view that, just as
> there's room in the world for more than one Pro Tools book, there's room in
> the world for more than one introduction to Csound.

so thanks to your publisher, too, for his wise encouragement ...
your book has qualities the floss manual will never have: a homogenous
(and excellent) style of writing, a focus on the essentials of learning
csound, from the background of your deep knowledge over the decades. as
mike said, it really fills a gap, and i will recommend it at the first
place for anyone who wants to learn csound.
the floss manual has some advantages, on the other hand, because it's
online, so it can accompany the changes of csound over the years. it's
excellent to have both, and hopefully a next Csound Book, which again
will have another focus and audience.
congratulations, jim, i hope your book will have the success it
deserves! by this, your publisher will also be able to continue his
encouragements ...

	joachim

After taking a look at the limitations of csbeats, I think I can see how a
new type of score syntax might work. Here's a simple example:



t0 100

; the new c (count) time signature statement -- p1 is bar number, p2 is
numerator, p3 denominator
c 1 4 4
; the new d (duration) statement affects the duration values in p3 until
changed -- it defaults to 1:
d 1

;	onset time		duration	standard	standard	arbitrary parameters
;	in bars/beats			pitch		dynamic
;	/ticks						level

i1   2.1			q		A3		ff		0.5	2	1000
i1   .			.		C#4
i1   .			.		E4

; duration is now shortened to 0.8 times symbolized value:
d 0.8

;    ticks default	compound	standard pitch		standard dynamic		arbitrary
parameter(s)
;    to 0 unless		duration	symbol not used,		symbol not used,
;    stated			symbol	so raw value passed	so raw value passed
;						to instrument		to instrument

i2	2.3.60		q+de		5.17				0.75				11.2 

Sorry -- looks like the columns just aren't going to line up neatly,
depending on the text display you're using....

Details might need lots of tweaking, but it seems to me that's a framework
that might be possible. Note that some sequencers use a bar/beat/16th/tick
format -- 2.1.3.57. If we're trying to make the format look
musician-friendly, I would definitely suggest that the first 16th-note in a
beat is 1, not 0. However, the first tick would be 0. A value of 60 ticks
per 16th-note would be 240 ticks per quarter, a resolution of about 2ms at
120 bpm. That's probably sufficient.

That's my 2 cents, anyway.

--
View this message in context: http://csound.1045644.n5.nabble.com/Note-duration-value-converter-idea-tp5537885p5559619.html
Sent from the Csound - General mailing list archive at Nabble.com.

http://csound.1045644.n5.nabble.com/file/n5559625/cscore.txt cscore.txt 

Here's a text file that has the column alignment (I hope).

--
View this message in context: http://csound.1045644.n5.nabble.com/Note-duration-value-converter-idea-tp5537885p5559625.html
Sent from the Csound - General mailing list archive at Nabble.com.

Okay, here's a more formal proposal for a way to expand the score language. I
have no idea what the technical issues might be in doing this -- I'm just
looking at it from the UI side. Richard, perhaps you can weigh in on whether
you feel this type of approach would be a boon for your students.

1) A new c score statement would define the base for the count (the time
signature). A c statement at the beginning of a score section would define
that section as using the new syntax. If no c statement is present, the
score section would be interpreted in the standard way.

2) The c statement would have three p-fields. p2 would define the numerator
for the time signature, and p3 the denominator. p1 would state the bar on
which this time signature begins. For instance:

c 1 4 4
c 7 5 8
c 21 7 4

The first c statement would have to have a p1 of 1. Only integers would be
meaningful for p1, as a new time signature must start on a bar line; and for
p2, as each bar would have to have an integer number of beats. p3 would be
interpreted, as it is in conventional staff notation, as a fraction of a 4/4
bar: A 4 means that the beat unit is a quarter-note, a 16 that it's a
16th-note, and so on. It's possible that p3 values such as 6 and 12 might be
meaningful, but it's not clear to me how such a denominator would relate to
the tempo.

As anyone who has worked with a MIDI event list knows, specifying the onset
times of quintuplets and septuplets in clock ticks is rather an annoyance.
For this reason, it might be useful to include the subdivisions-per-beat and
sub-subdivisions-per-beat within the c statement. For instance --

c 1 4 4 7 11

-- would set the 4/4 meter to use 7 "16th-notes" per quarter-note, and 11
clock ticks per septuplet. These p-fields would default to 4 and perhaps 96
if not specified. 

3) i-statements in the new score format would allow (but not enforce)
certain symbolic conventions. This would probably mean that a score section
in the new syntax would be run through a new pre-processor stage that would
look through the i-statements and replace the symbolic values with
conventional p-field values before the normal score processing occurs. Thus
i-statements in the new format could be mingled freely (perhaps with some
restrictions that I haven't anticipated) with i-statements of the usual
type.

4) p1 would have its usual meaning.

5) A value of p2 that is an integer, a number with one decimal point, or a
symbol of an existing type (+, etc.), would be interpreted in the usual way.
However, an entry for p2 that had two or three decimal points would be
interpreted as a symbol referring to bars/beats/16ths (if there are two
decimal points) or bars/beats/16ths/clock ticks (if there are three). These
symbols would be interpreted with reference to the start of the section:
1.1.1 would refer to the very beginning of the section (bar 1, beat 1,
16th-note 1) and so forth.

6) In the case of a time signature such as 6/8 or 11/16, where the
eighth-note or 16th-note gets the beat, two questions arise. First, how
would a bar/beat/16th value specifying a higher-numbered 16th-note than the
meter allows be handled? Second, what is the meaning of the tempo, as
defined by the t statement, when the basic beat is not a quarter-note? (To
facilitate time signature changes from 4/4 to 11/16 or whatever, I would
suggest that the tempo always apply to quarter-note groups of events. This
may get a little tricky....)

I would suggest that 16ths be incrementable from the start of the specified
beat with no restriction based on the number of "allowed" 16ths. And by
extension, the number of beats would not be limited to the number defined by
the time signature, nor would the number of clock ticks be limited. That is,
assuming a time signature of 4/4 (a c statement such as c 1 4 4), a p2 of
1.3.7 would have the same meaning as 1.4.3, because the 7th 16th-note of
beat 3 is the same as the third 16th-note of beat four. Likewise, in 4/4, a
note at 3.5.1 would be the same as a note at 4.4.1, because the fifth
quarter-note of bar 3 is identical to the first quarter-note of bar 4. If
ticks are being specified and there are 96 ticks per 16th-note, a note at
1.1.1.104 would be the same as a note at 1.1.2.8.

It could be argued that this scheme is needlessly complex, and that the
syntax should restrict the user to 'allowed' values for p2 symbols. But it
seems to me that it's useful to let the user write out a series of notes
without worrying too much about where the series happens to cross a beat or
bar line. This is especially true in the case of compound rhythms.

7) Presumably, only one bar/beat grid would be allowed per section (just as
each section now has only one time clock). Allowing multiple simultaneous
time signatures (or, indeed, multiple simultaneous tempi) is not an
impossible musical idea by any means, but it would undoubtedly be tricky to
implement. (One idea would be to allow Csound to run several simultaneous
sections. But that's a different topic.)

8) A value of p3 that is a number would be interpreted in the standard way.
A p3 that contains text characters would be interpreted symbolically as a
conventional rhythm value based on the current tempo, and translated by the
pre-processor:

q = quarter-note
e = eighth-note
s = 16th-note
h = half-note
w = whole-note
t = 32nd-note
x = 64th-note
d means dotted
dd means double-dotted
3 means triplet
5 means quintuplet
7 means septuplet

So, for instance, a p3 of q3 would produce a duration of a quarter-note
triplet at the current tempo, sd would produce a dotted sixteenth, and so
on. Other values could be produced using + to indicate a value that would be
shown in staff notation by a tie. For instance, q+s3 would produce a
duration of a quarter-note plus a 16th triplet, and w+w would produce a
double whole-note.

9) We might imagine two modest additions to this symbol set. A tenuto mark
(symbolized by a hyphen or an underscore) might add a small amount to the
duration, while a staccato mark (symbolized by a period) would reduce it by
a small amount. The precise meanings of the tenuto and staccato would have
to be defined by a score statement, such as a d (for duration) statement.
The values might need to change during the course of the piece, so a d
statement would have a p1 that indicates the bar/beat/sixteenth on which it
takes effect, p2 would indicate the percentage of the specified duration for
a staccato (default perhaps 0.65), and p3 would indicate the percentage for
a tenuto (default perhaps 1.2).

10) A symbolic value of p4 (fff, ff, f, mf, mp, p, pp, or ppp) would
translate in some way to an amplitude value that could be applied to ampdb
or some similar opcode -- I'm hazy on the details. A numerical value for p4
would be passed to the instrument without alteration. If finer gradations
are desired, a suffixed > character could indicate an accent. mf> would then
be intermediate in value between mf and f.

11) A symbolic value of p5 (C2, C#3, Ab4, etc.) would be translated by the
pre-processor into a Hz value with a reference of A-440 and 12EDO tuning. A
numerical value of p5 would be passed to the instrument without alteration.

12) Any subsequent p-field values would be passed to the instrument without
alteration, and with the usual optional symbols (~, >, etc.) interpreted by
the score processor in the usual way.

That's tonight's brainstorm. I really do think a system of this sort would
be a good addition to Csound, and it might not be insuperably difficult to
implement. Also, it would be fully backward-compatible: In the absence of a
c statement, a score would be interpreted just as it is now.

--
View this message in context: http://csound.1045644.n5.nabble.com/Note-duration-value-converter-idea-tp5537885p5560131.html
Sent from the Csound - General mailing list archive at Nabble.com.

On 13/03/2012 14:28, Jacob Joaquin wrote:
> If building something directly into the score doesn't work, why not
> build a preprocessor framework where users can build and share their own
> systems? Which be infinitely more useful, providing it is fully
> supported and doesn't become vapor ware later.
>

I am minded to suggest the other way round. It seems clear that there 
are as many opinions on what a mensuration score language should look 
like, as there are users. The logic points to the sequence of developing 
N examples of a scoring preprocessor ~first~, in just the way you 
describe, using whatever scripting languages people choose ( I suppose 
Perl and Python are the leading candidates for a text processing form; 
csbeats is more sophisticated by being defined as a true language using 
flex/bison), and only once a certain consensus has been reached, 
settling on a form for the 'canonical' system (assuming there has to be 
just the one!)  to be integrated into Csound. Who knows - maybe the 
latter step may  be found to be unnecessary after all!

Richard Dobson

... and perhaps there is a case for arranging a distinct web repository 
for score preprocessors, to enable quick browsing and comparisons?

Richard Dobson

> The score language is what it is, and probably won't change much (unless
some drastic design
> changes are made in Csound6). With that in mind, designing a new canonical
> system of notation
> to include into Csound is a very rigid process, and will never satisfy all
> but a handful of people.
> So we're stuck with the score language, for better or worse.

> The only course of action that makes sense when confronted with this
> reality is for composers
> to write their own score preprocessors, or score generators. This being
> the case, the best thing
> we can do (okay, maybe not the best thing) is to create a framework that
> allows quick
> development of score generators and score preprocessors.

I disagree, for two reasons.

First, the score language can be expanded a great deal, as my proposal
shows, without sacrificing backward compatibility. It has, in point of fact,
_already_ been expanded over the years in all sorts of interesting ways --
with macros, embedded expressions, random value operators, loops, and so on.

Second, the whole point of expanding the score language to include
bar/beat/tick rhythms and other conventional value symbols is to make Csound
more approachable for newcomers. Newcomers are not going to stroll out and
write their own score preprocessors. Suggesting that that is "the only
course of action that makes sense" is just silly, because it doesn't make
sense at all.

Sorry to be so blunt, but I think this is a pretty good example of the kind
of elitism that Richard was objecting to.

--
View this message in context: http://csound.1045644.n5.nabble.com/Note-duration-value-converter-idea-tp5537885p5562121.html
Sent from the Csound - General mailing list archive at Nabble.com.

On 13/03/2012 18:36, Jim Aikin wrote:
..rs.
>
> I disagree, for two reasons.
>
> First, the score language can be expanded a great deal, as my proposal
> shows, without sacrificing backward compatibility. It has, in point of fact,
> _already_ been expanded over the years in all sorts of interesting ways --
> with macros, embedded expressions, random value operators, loops, and so on.
>


This is actually part of the concern - we will need all these things to 
remain available with (and not broken by) the new notation. Thus 
includes, not least, the negative p3 mechanism for tied notes, etc. 
There is an example in Issue 15 of the Csound Journal - "Microcsound" 
which expressly maintains support for negative p3. While the paper 
address specifically microtonal composition, it also speaks to the 
current topic, and would be well worth people reviewing in this context.


> Second, the whole point of expanding the score language to include
> bar/beat/tick rhythms and other conventional value symbols is to make Csound
> more approachable for newcomers. Newcomers are not going to stroll out and
> write their own score preprocessors. Suggesting that that is "the only
> course of action that makes sense" is just silly, because it doesn't make
> sense at all.


This is ~not~ the suggestion (well, not mine, anyway). The suggestion is 
that, pro tempore, they look at one or other of the score preprocessors 
already published (including but not limited to csbeats). One problem is 
that some or all of these have not been sufficiently publicised, so in 
effect nobody knows about them. This is why I suggest a central resource 
(maybe a new page on Csounds.com linked from the "resources" page) with 
pointers to the known available preprocessors. John indicated that 
csbeast is built by default in the latest update

The danger is that a hasty addition to the existing score language may 
risk breaking existing functionality or (as important) compromising 
future developments, e.g. by taking short-cuts later found to be 
unfortunate. Given the wide difference of priorities for the various 
interested parties, the chances of a solution that works for one group 
being less than ideal for another are pretty high.

Changing the standard score notation is, however one looks at it, a Big 
Deal and worth at least discussing ~before~, rather than after, 
implementation. It would not be the first time that issue has arisen. 
And in the end there is no one "elite" Csound group - there are any 
number of them!

Richard Dobson

Just to add a couple 0of minor points.  I am VERY happy to extend csbeats
in a way that woreks for the community who think notes, beats etc.  It is
just that thought out proposals are needd that I can understand!

Secondly I do not relate to quarter notes; to me a q is a quaver.  I do
not know what the translation of breve or longe are to this format.  OK so
i am an elitist who speaks English.....  but why assume that eigth notes
are meaningful?

==John ff


>
> This is actually part of the concern - we will need all these things to
> remain available with (and not broken by) the new notation. Thus
> includes, not least, the negative p3 mechanism for tied notes, etc.
> There is an example in Issue 15 of the Csound Journal - "Microcsound"
> which expressly maintains support for negative p3. While the paper
> address specifically microtonal composition, it also speaks to the
> current topic, and would be well worth people reviewing in this context.
>
> This is ~not~ the suggestion (well, not mine, anyway). The suggestion is
> that, pro tempore, they look at one or other of the score preprocessors
> already published (including but not limited to csbeats). One problem is
> that some or all of these have not been sufficiently publicised, so in
> effect nobody knows about them. This is why I suggest a central resource
> (maybe a new page on Csounds.com linked from the "resources" page) with
> pointers to the known available preprocessors. John indicated that
> csbeast is built by default in the latest update
>
> The danger is that a hasty addition to the existing score language may
> risk breaking existing functionality or (as important) compromising
> future developments, e.g. by taking short-cuts later found to be
> unfortunate. Given the wide difference of priorities for the various
> interested parties, the chances of a solution that works for one group
> being less than ideal for another are pretty high.
>
> Changing the standard score notation is, however one looks at it, a Big
> Deal and worth at least discussing ~before~, rather than after,
> implementation. It would not be the first time that issue has arisen.
> And in the end there is no one "elite" Csound group - there are any
> number of them!
>
> Richard Dobson
>

This is a good example of the depth and range of the issue.  As it 
stands (and will necessarily continue to stand) the canonical Csound 
score is a note list. Therefore  the next step up is a preprocessor that 
also describes a notelist.

On the other hand, there is a clear desire for a much more algorithmic 
and generative approach. Now, the former might be regarded as a subset 
of the latter, but conceptually I think they are distinct. They could 
well be related in that way, ~if~ they are compatibly designed. If there 
are multiple opinions about the best format for a note list, there will 
be even more about a language for algorithmic work.

The common denominator will of course remain the canonical Csound sorted 
notelist, in effect the "machine code" that the higher-level systems 
will output.

If such a modern score language "resembles the look of modern scripting 
languages", does that not rather suggest that using an existing 
scripting language would do just as well anyway? I wonder if the best 
reason for developing a new score language would be not simply to have a 
new language but to to be able to incorporate dedicated audio and 
music-specific idioms (not directly available in existing scripting 
languages), whatever those turn out to be  - first-class constructions 
for phrases, sections, voice-leading, microtones, custom scales, and so on?

Richard Dobson






On 13/03/2012 19:34, Jacob Joaquin wrote:
> I have a great many notes on what a modern score language may look like.
> And much of it resembles the look of modern scripting languages. The
> traditional computer music score is very limited, and adding a couple of
> extra features here and there doesn't even begin to approach what a
> scripting language could bring to the table. For example,  here's a
> python granular event generator. 100,000 events over 60 seconds:
>
> from random import random
>
> for i in range(100000):
>      print "i 1 " + str(random() * 60.0) + " 0.05 0.02 " + str((100 +
> random() * 1000))
>
> I would also like to add a couple suggestions to Csound6. Two way
> communication between score and orchestra. Callbacks. Asynchronous events.
>

> If such a modern score language "resembles the look of modern scripting
> languages", does that not rather suggest that using an existing
> scripting language would do just as well anyway? I wonder if the best
> reason for developing a new score language would be not simply to have a
> new language but to to be able to incorporate dedicated audio and
> music-specific idioms (not directly available in existing scripting
> languages), whatever those turn out to be  - first-class constructions
> for phrases, sections, voice-leading, microtones, custom scales, and so on?

For the record, this is exactly what I have been doing with Surmulot, 
the scripting language being Smalltalk.

Not completely documented, and definitely not for newcomers though.

Stef

Well, I think that just about clinches it. There are quit a few 
solutions out there; and for beginners (or for writing relatively plain 
note lists, anyway) it looks like csbeats is the primary candidate.

Probably all it could do with on top of what it already does is the 
ability to allow further arbitrary standard pfields verbatim to the 
final sorted score, effectively p6 onwards. Given the existing notation, 
either enclosed in quotes or using some other separator. Even if it 
could be done without that, I think  such a symbolic separation would 
enhance readability.

I also think the dynamic mark dB increment (1dB per step ) is too small; 
3dB per step would not be at all extreme. I suppose that means that it 
would be something worth specifying from the score  - say, minimum  step 
1dB, max step 6dB.

Then there is tempo warping as per the t statement, negative p3, score 
sections, and... a few more tuplets?


Richard Dobson


On 13/03/2012 22:02, Stéphane Rollandin wrote:
>> If such a modern score language "resembles the look of modern scripting
>> languages", does that not rather suggest that using an existing
>> scripting language would do just as well anyway? I wonder if the best
>> reason for developing a new score language would be not simply to have a
>> new language but to to be able to incorporate dedicated audio and
>> music-specific idioms (not directly available in existing scripting
>> languages), whatever those turn out to be - first-class constructions
>> for phrases, sections, voice-leading, microtones, custom scales, and
>> so on?
>
> For the record, this is exactly what I have been doing with Surmulot,
> the scripting language being Smalltalk.
>
> Not completely documented, and definitely not for newcomers though.
>

Hi All,

(Long email warning :) )

This discussion has brought up some very interesting points from
across the board.  I think from the breadth and depth of the
conversation we can all agree that there are a lot of details and some
subtle issues involved here. I thought I'd try to recap, as well as
offer some other things to think about.

First, there are a number of points of view: the user who does not
code, the user who does code, the programmer working on the internals
of Csound, and the programmer using Csound as an audio programming
library. Even within the first category, there are divergent views on
what notations should be supported.  Ideally, we want a solution that
works for all of these different perspectives. This is to say,
whatever solution to the problems are, it should be done in a way that
is not going to cause problems for the others.

Second, the discussion of the score should, in my opinion, take into
account past discussions about MUSIC-N based languages, discussing the
question of "score as code" and "score as data".  A month or so ago,
Victor had pointed me to a couple of articles in which this topic came
up:

Machine Tongues XIX: Nyquist, a Language for Composition and Sound Synthesis
Author(s): Roger B. Dannenberg
Reviewed work(s):
Source: Computer Music Journal, Vol. 21, No. 3 (Autumn, 1997), pp. 50-60

Machine Tongues XV: Three Packages for Software Sound Synthesis
Author(s): Stephen Travis Pope
Reviewed work(s):
Source: Computer Music Journal, Vol. 17, No. 2 (Summer, 1993), pp. 23-54

Currently in Csound, we have a "score as data" model.  While there are
some things that are just not possible unless you go with a "score as
code" model, on the whole, I really believe that "score as data" is
one of the biggest reasons Csound has endured for so long, and why
other synthesis systems have not.  By having a generic data format, it
has allowed the community to supply their own means of
writing/generating that data, whether it is by a scripting language
(i.e. python, tcl, perl, etc.), a GUI-based program (i.e. Cecilia,
blue, AVSynthesis), or custom preprocessor (i.e. ngen, cmask, etc.).
Ultimately, the test of time has shown that it works.  (To note, this
is also why I made the comparison to MIDI as it is a data format as
well; this point was perhaps not explained well in my earlier emails.)

Now, when we have our user's hat on and are working with Csound, we
all want to write things in the way that makes the most sense to us
and is the most convenient syntax. If I remember correctly, Max
Mathews wrote in his Technology of Computer Music about "protecting
the dignity of the composer" and about letting them notate things in
convenient notation (working off memory here). The solutions there
involved writing Fortran code for Music-V and using them as PLS
routines.  The equivalent feature is cscore in Csound.

However, what I think worth noting is that Music V and Csound both
allowed a generic solution for customization.  Both though pre-date
common use of scripting languages and separate score preprocessors,
and I think the spirit of those are expressed in the latter.

To understand the design then from the above, regardless of how the
user wrote their scores, internally it was always represented in a
real-time duration in seconds.  This is the case today with Csound,
where the score processing is done and the score is sorted down to
realtime values. In terms of design, this allows a great deal of
flexibility as all other expressions of time can be expanded and
represented into realtime values.

Now, the context of computer music software has changed.  We're in a
situation where have these mixed levels of computer literacy all
working in the same Csound domain.  Now, we all want to work in ways
that seem the most natural for the models of music we have in our
heads.  Using an 8 as an eighth note duration makes sense to some, and
not so much for others, just as a crotchet or the note name H doesn't
make much sense for those not trained in England or Germany
respectively.  The more interesting problem to consider from it is,
can we find a solution that allows these notations in a generic way,
that will least impact Csound itself?

Well, we know using external programs work.  On the whole, most who do
are working with some awareness of the program as a separate entity
from Csound.  Also, there has generally been an additional overhead to
learning how to work these programs together.  This can understandably
be difficult pedagogically to justify (yet another thing to teach),
especially as the general level of computer literacy is not the same
as it was 10, 20 years ago.

John ffitch added a very nice feature to CSD's of the bin= property
which allows writing the contents with a CsScore section to be
anything that will be interpreted by an external program.  This has a
number of positives: it gives the illusion of having a different score
language within Csound itself, it simplifies the use of external tools
by integrating the score preprocessor as part of the compilation
process, and it also builds on top of what exists within Csound rather
than trying to add anything custom.  (I have to say that a similar
feature has existed in blue with the External SoundObject, so I am
perhaps biased to this design.)

So we have two solutions to the notation problem already that both go
through external programs, either directly or indirectly through
csound.

Now, one other problem to consider: the use of an external program via
the bin= property requires that external program to be installed.
This limits the long-term viability of a Csound project, as it puts a
hard dependency on an external program.  This isn't a huge limitation,
though, and is just something to be aware of.  For example, if you
write a CSD that requires perl, and I do not have that installed, I
will not be able to run your project.  Another problem is introduced
via mobile platforms, where running an external program via pipe is
often not possible.

So, there is a third solution to consider, one that would require
development but I think would be a generic solution.  We could create
score preprocessor plugins. Like the opcode libraries, which can
provide opcodes, gen routines, audio IO, etc., we can have separate
pre-processors that are pluggable.  These can be registered by name,
so one could do something like "--sco-process=MyScoreRoutine" (or some
other means to choose what to use to process).  This would allow some
routines to be built together with Csound, as well as plug-in types as
well.

This really then could be seen as a modernization of Cscore from being
just a single compile-time score processor, to being a run-time
pluggable cscore.  (Though, cscore uses data structs, and not string
data, so that's not quite accurate, but the general idea isn't that
far off). It also allows Csound internally to remain consistent as-is,
and does not further complicate the existing codebase.

To note: from my own work, the SoundObjects and NoteProcessors within
blue are essentially a set of score generators and processors.  They
cover many different representations of time and musical material, yet
are able to coexist.  They are able to do so because blue itself has a
very generic notion of note data, but all of the other stuff is made
possible because the internal representation is generic.  I've seen
how this design can support different high-level musical models, which
is why I think something similar needs to be maintained in Csound.

Okay, hope that helps frame the problems and issues a bit more
clearly.  I think the two solutions we already have for scoring are
already quite flexible, and that the 3rd option has some interesting
possibilities (though, I'm sure there are  drawbacks too).

Thanks,
steven

On Tue, Mar 13, 2012 at 8:17 PM, Richard Dobson
 wrote:
> This is a good example of the depth and range of the issue.  As it stands
> (and will necessarily continue to stand) the canonical Csound score is a
> note list. Therefore  the next step up is a preprocessor that also describes
> a notelist.
>
> On the other hand, there is a clear desire for a much more algorithmic and
> generative approach. Now, the former might be regarded as a subset of the
> latter, but conceptually I think they are distinct. They could well be
> related in that way, ~if~ they are compatibly designed. If there are
> multiple opinions about the best format for a note list, there will be even
> more about a language for algorithmic work.
>
> The common denominator will of course remain the canonical Csound sorted
> notelist, in effect the "machine code" that the higher-level systems will
> output.
>
> If such a modern score language "resembles the look of modern scripting
> languages", does that not rather suggest that using an existing scripting
> language would do just as well anyway? I wonder if the best reason for
> developing a new score language would be not simply to have a new language
> but to to be able to incorporate dedicated audio and music-specific idioms
> (not directly available in existing scripting languages), whatever those
> turn out to be  - first-class constructions for phrases, sections,
> voice-leading, microtones, custom scales, and so on?
>
> Richard Dobson
>
>
>
>
>
>
>
> On 13/03/2012 19:34, Jacob Joaquin wrote:
>>
>> I have a great many notes on what a modern score language may look like.
>> And much of it resembles the look of modern scripting languages. The
>> traditional computer music score is very limited, and adding a couple of
>> extra features here and there doesn't even begin to approach what a
>> scripting language could bring to the table. For example,  here's a
>> python granular event generator. 100,000 events over 60 seconds:
>>
>> from random import random
>>
>> for i in range(100000):
>>     print "i 1 " + str(random() * 60.0) + " 0.05 0.02 " + str((100 +
>> random() * 1000))
>>
>> I would also like to add a couple suggestions to Csound6. Two way
>> communication between score and orchestra. Callbacks. Asynchronous events.
>>
>
>
> 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"
>

> Just to add a couple of minor points.  I am VERY happy to extend csbeats
> in a way that works for the community who think notes, beats etc.  It is
> just that thought out proposals are needed that I can understand!

I was trying to expand on the idea of csbeats in my proposal. Was there
anything in it that you didn't understand?

> Secondly I do not relate to quarter notes; to me a q is a quaver.  I do
> not know what the translation of breve or longe are to this format.  OK so
> i am an elitist who speaks English.....  but why assume that eighth notes
> are meaningful? 

I think we would need to do a survey of Csound users from Europe and beyond
to find out what percentage are comfortable referring to quavers,
semiquavers, demisemiquavers, and hemisemidemiquavers. To my way of thinking
(and yes, I live in the U.S.), those terms are rather archaic, being based
as they are on Medieval terminology.

I seem to recall that a half-note is called a breve because it was, at one
time, the _short_ note, a quaver (a quarter-note) being even shorter and
thus no more than an ornament or trill flourish. But just as the pitch of A
has risen over the centuries, music has gotten faster. A breve is no longer
a short note, and a quaver is more than just a quiver.

The terminology whole-note, half-note, quarter-note, eighth-note, etc., is
based on fractions of a bar of 4/4. It seems to me that this metric
structure is unlikely to undergo any radical alteration in the next hundred
years; it hasn't done so in the past 200. That being the case, it seems to
me that these terms are likely, moving forward, to be understood by far more
musicians than the Medieval terms, as well as easier to abbreviate.
("hsdq"???)

--
View this message in context: http://csound.1045644.n5.nabble.com/Note-duration-value-converter-idea-tp5537885p5562885.html
Sent from the Csound - General mailing list archive at Nabble.com.

> Hi All,
>
> (Long email warning :) )
[...]
>
> Thanks,
> steven

This is a brilliant summary IMO. Thanks.

Stef

> I think we would need to do a survey of Csound users from Europe and beyond
> to find out what percentage are comfortable referring to quavers,
> semiquavers, demisemiquavers, and hemisemidemiquavers. To my way of thinking
> (and yes, I live in the U.S.), those terms are rather archaic, being based
> as they are on Medieval terminology.

As a French person, my understanding is that those terms are simply the 
correct English ones.

Stef

On 13/03/2012 23:08, Jim Aikin wrote:
..
>
> I think we would need to do a survey of Csound users from Europe and beyond
> to find out what percentage are comfortable referring to quavers,
> semiquavers, demisemiquavers, and hemisemidemiquavers. To my way of thinking
> (and yes, I live in the U.S.), those terms are rather archaic, being based
> as they are on Medieval terminology.
>
> I seem to recall that a half-note is called a breve because it was, at one
> time, the _short_ note, a quaver (a quarter-note) being even shorter and
> thus no more than an ornament or trill flourish. But just as the pitch of A
> has risen over the centuries, music has gotten faster. A breve is no longer
> a short note, and a quaver is more than just a quiver.
>


All we need to do is to remember that, either way, these are names, not 
quantities. We do not have seventh-notes or even third-notes. Since they 
are names, there is no overwhelming reason why we cannot choose to use 
one or the other ad lib, perhaps declared via a score directive. I do 
not see that "double-dotted quarter note" is necessarily more expressive 
than "double-dotted crotchet". And the irony of this is that in many 
ways the crotchet/quarternote is typically thought of these days of as 
"the unit" of a beat, so that a half-note is really thought of as a 
double unit. So while the fraction name has a certain logic to it, it is 
still not as logical as it ~could~ be. And if someone types a 9 where 
they should have typed an 8, that is a spelling mistake, not a math error.

Richard Dobson

There are many options. I would categorize them as follows:

(1) Csound is a synthesizer embedded in a notation program. This
actually is possible and I am experimenting with using CsoundVST in
Sibelius 7 right now. You see triplet 16ths in 12/8, you get them.

(2) Csound reads MusicXML output by a notation program. This is
possible either (a) through the Csound API or (b) through a special
tag in the csd file that invokes an external program to produce the
standard numeric score (or whatever it is, it doesn't seem to be in
the manual).

(3) The composer creates a special program that knows about musical
semantics in the way the composer wishes. csbeats is an example of
this.

(4) The composer uses a scripting language and defines a
"domain-specific" score language that will use functions written by
the composer to parse the composer's score into a Csound score. This
frankly is the easiest thing to get going but of course it is not
"built in" to Csound.For this to work, Csound must be used as plugin
or library by the composer's parser or composition.

Then as I suggested a few days ago:

(5) In Csound 6, the score parser can be abstracted from the
low-level, sorted score language. This layering already is implicit in
the existence of the sorted score. What would be new would be
additional, built-in score syntaxes. For example, csbeats could become
a built-in part of Csound with this approach. Or something like
csbeats. Or a form of MusicXML that doesn't just pay attention to
musical time (as the current facility does) but also to bars and beats
and meters (MusicXML has two layers of time semantics as well). The
 tag could take attributes, e.g. ,
, or .

Regards,
Mike

On Tue, Mar 13, 2012 at 11:29 AM, Jacob Joaquin  wrote:
> I haven't thought all of this stuff all the way through, so keep in mind
> everything I'm about to say I may personally disagree with later.
>
> Csound needs to be more flexible. The score language is what it is, and
> probably won't change much (unless some drastic design changes are made in
> Csound6). With that in mind, designing a new canonical system of notation to
> include into Csound is a very rigid process, and will never satisfy all but
> a handful of people. So we're stuck with the score language, for better or
> worse.
>
> The only course of action that makes sense when confronted with this reality
> is for composers to write their own score preprocessors, or score
> generators. This being the case, the best thing we can do (okay, maybe not
> the best thing) is to create a framework that allows quick development of
> score generators and score preprocessors.
>
> But then again, after reading everything I just wrote, I have a feeling
> having that a framework like the one I just proposed could easily muck
> things up even further. I have not idea what I'm talking about.
>
>
>
>
>
> On Tue, Mar 13, 2012 at 7:55 AM, Richard Dobson
>  wrote:
>>
>> ... and perhaps there is a case for arranging a distinct web repository
>> for score preprocessors, to enable quick browsing and comparisons?
>>
>> Richard Dobson
>>
>>
>>
>> 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"
>>
>
>
>
> --
> codehop.com | #code #art #music



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

I decided to take the idea of a framework one step farther utilizing
the python sco parsing library I wrote a couple years back. More or
less, I implemented the original idea as presented by Brian Simmons.
Haven't gotten it to work with CsScore bin yet, but that should be the
next step.

In a nutshell, it translates:
i 1 0 4
i 1 + 4.1
i 1 + 4.2
i 1 + 4.3
i 1 + 4.4

into:
i 1 0 1.0
i 1 + 1.5
i 1 + 1.75
i 1 + 1.875
i 1 + 1.9375

And here's the script:
#!/usr/bin/env python
#
# Copyright (C) 2012 Jacob Joaquin
from csd import sco
import re
import sys

def dot(value, n_dots=0):
	if n_dots == 0:
		return value
	else:
		return value + dot(value / 2.0, n_dots - 1)

def main():
	# Get input
	s = ''.join(sys.stdin.readlines())

	# Select all i-events
	selected = sco.select(s, {0: 'i', 1: range(0, 1000)})

	# Process each i-event
	for k, v in selected.iteritems():
		# Get p3 value
		p3 = sco.event.get(v, 3);

		# Process if p3 is a number
		if p3.replace('.', '', 1).isdigit():
			n_dots = 0
			m = re.search('\.(\d+)', p3)
			dur = 1.0 / int(float(p3)) * 4.0
			
			if m:
				n_dots = int(m.group(1))

			# Update event row
			selected[k] = sco.event.set(v, 3, str(dot(dur, n_dots)));

	# print the results	
	print ''.join(sco.merge(s, selected))

if __name__ == '__main__':
    main()


All in all, it took about 2 hours. Mostly because my python is rusty,
and I had to remember what it was I was doing two years ago when I
wrote the library.

Best,
Jake

from Dr. Richard Boulanger:
>it is very important to support "musical" thinking in Csound at every 
level - especially
> in terms of bars, beats, measures, frames, etc...

One thing overlooked IMO in this discussion is that metered music is an 
intermediate representation. In an actual performance, written music is 
always interpretated so that the eventual rhythm is a natural, living 
one. Only recently with electronic devices did beats get to be actually 
felt by the listener in a strict, hard way.

With the Csound score, we have a problem: the written score is also the 
performance blueprint. Writing metered music in the score syntax will 
translate into mecanic peformance automatically.

That's the point of composing with an external software using Csound 
score as a low-level description for performance: you can think and 
write with musical meter, but also describe how to inject breath and 
suppleness in the performance. Here it makes sense that the score use 
seconds instead of beats. Beats are an abstraction layer above.

By the way, are you people aware of the transcription of piano rolls 
available here: http://members.shaw.ca/smythe/rebirth.htm ?

You can find there music played by Rachmaninoff himself, as plain MIDI 
files. With a decent piano soundfont, they sound amazing ! And of 
course, no note there lands on a beat, ever.



Stef

On 14/03/2012 09:23, Stéphane Rollandin wrote:
> from Dr. Richard Boulanger:
>> it is very important to support "musical" thinking in Csound at every
> level - especially
>> in terms of bars, beats, measures, frames, etc...
>
> One thing overlooked IMO in this discussion is that metered music is an
> intermediate representation. In an actual performance, written music is
> always interpretated so that the eventual rhythm is a natural, living
> one. Only recently with electronic devices did beats get to be actually
> felt by the listener in a strict, hard way.
>


I am guessing that the latter is actually the goal here, in the original 
request - the archetypal club dance track is utterly pegged to the 
clock, peaking somewhere around mm=180. The only exception would be any 
vocals (and even there, Autotune rules). The relentless clock-tight 
patterns and rhythms undeniably have an effect on the brain, endorphins 
etc, which I also guess is precisely the point. I am dimly aware of 
research into the rubato practice of acoustic performers, but I  suspect 
it is not yet at a sufficiently advanced stage to encode in any simple 
way in Csound.  And so long as composers specify times in seconds only 
to two decimal places, the result, in practice, is still pretty strongly 
quantised.

There are a few simple heuristics for rubato, such as the degree of 
magnetic atttraction of a principal beat (tempo slightly faster the 
closer notes are to the beat), the trick being to set those principal 
beats as far apart as possible - the distance of a slow human breath, 
say. This can partly account for tricks such as anticipations and delays 
"en route", but most of them arise from the demands of rhetoric and, to 
some extent, from personal style, and, dare I say it, are probably 
non-algorithmic in nature.

Richard Dobson

There are ways to get pleasant free rhythms from algorithms, I have been 
working on this for ages. I do not attempt to imitate the playing of 
human performers though, only to produce "breathing" computer music.

Stef

On 14/03/2012 11:33, peiman khosravi wrote:
>
>
>
>     I am guessing that the latter is actually the goal here, in the
>     original request - the archetypal club dance track is utterly pegged
>     to the clock, peaking somewhere around mm=180.
>
>
> yes and no. Dance music is metrically and spectraly a lot more intricate
> than it is often given credit for. I'm thinking for instance of the
> slight lagging or offsetting of the hi-hats. They may be following the
> clock rigidly but by using smaller or odd bar divisions one can create
> quite complex rhythmic patterns that avoid the mechanical feel.

Indeed; but that sort of complexity is intrinsically different from 
"humanistic" variations.


> Nancarrow being a good example, of course he takes it to the extreme.
>

It would be fab if Nancarrow got played in the clubs!

My master plan one day is to write a mostly predictable dance track, but 
with the occasional 17/16 bar "just for fun".

Richard Dobson