Maybe could be helpful:

http://www.csounds.com/manual/html/pset.html

ciao,
francesco.




--
View this message in context: http://csound.1045644.n5.nabble.com/Default-values-for-p-fields-tp5721991p5722019.html
Sent from the Csound - General mailing list archive at Nabble.com.

Hi All,

Jake's example reminded of some instrument design thoughts I've had
and wanted to share, so I'm going a bit offtopic from Jake's offtopic.
:P

Csound instruments can easily have per-note values, but having
per-instrument values can simplify instrument note design so that
instruments can be configurable but still be reused easily if they
share the same pfield signature.  This is common in MIDI instruments,
which all conform to the same event messaging protocol for per-note
values (i.e. pitch velocity), but have per-instrument values
configured via sysex/OSC/direct UI control, etc.

I explored this a bit in:

http://www.csounds.com/journal/issue13/emulatingMidiBasedStudios.html

One can see it in the SawBody instrument, where chnget is used to read
the current value of a cutoff frequency for moogladder.  That value
can be changed independently of the note events.  Note the instr 1 and
instr 2 in the example, how they are used in the score to modify
configurable values for an instrument.

In Blue, I often write things like i()  where  is a
gk-var value that blue generates.  This allows that when an instrument
instance starts, it will read the current value that is generated from
a knob or slider, and use that as the attack time to linsegr or adsr.
(I'm sure that users using Cabbage and CsoundQT probably end up doing
something similar)

Anyways, a bit off-off-topic now, but just wanted to mention that.

Thanks!
steven


On Tue, Apr 16, 2013 at 3:43 PM, Jacob Joaquin  wrote:
> Off topic, though this is one of the issues I'm attempting to address with
> PythonScore. The idea is to allow composers to create simpler interfaces to
> instruments with lots of pfield arguments. For example, here are the pfields
> for a kick drum synth I'm working on:
>
> instr 2
>     p3 = p4
>     idur = p4
>     iamp = p5
>     ifreq1 = p6
>     ifreq2 = p7
>     itrans_dur = p8
>     itrans_amp = p9  * 0.5
>     itrans_freq = p10
>     itrans_lp = p11
>     ixfade = p12
>     ixfade2 = p13
>     ieq_amp = p14
>     ieq_freq = p15
>     ieq_reson = p16
>
>     ....
>
> That's a lot of input for a kick. A classical Csound score event looks
> something like this:
>
> i 2 0 1 0.1333 0.707 200 50 0.01 4 900 900 0.02 0.05 0.5 200 0.3
>
> There are multiple approaches in PythonScore for creating a cleaner
> interfaces to instruments loaded with pfield inputs. For example, this
> function only requires the start time, amplitude, and an option for the
> transient amp:
>
> def my_kick(start, amp, transient_amp=4):
>     score.i(2, start, 1, 0.1333, amp, 200, 50, 0.01, transient_amp, 900,
> 900, 0.02, 0.05,
>                 0.5, 200, 0.3)
>
> In use, it would look something like this:
>
> my_kick(0, 0.707, 6)
> my_kick(2, 0.707)
> my_kick(2.5, 0.707, 2)
>
> It would also be possible to create various other kicks using the same
> instrument, but with multiple PythonScore interfaces. Here's a very
> different sounding kick from the same instrument, but different function:
>
> def other_kick(start, dur, amp, transient_amp=4):
>     score.i(2, start, 1, dur, amp, 100, 50, 0.03, transient_amp, 8000, 1500,
> 0.04, 0.05,
>                 0.3, 75, 0.7)
>
> And they could be used together:
>
> my_kick(0, 0.707, 2)
> other_kick(2, 0.1, 0.707)
>
> Working this way is analogous to working with patches on a synth.
>
>
>
> On Tue, Apr 16, 2013 at 3:28 AM, Mark Brophy  wrote:
>>
>> If I define an instrument with 8 p-fields and specify only 5 using an
>> i-statement, how do I supply default values in the instrument for the
>> unspecified fields?
>
>
>
>
> --
> codehop.com | #code #art #music

not quite true, i think. of course (?!?), amongst the 1500+ opcodes, 
there is one to check the number of provided p-fields: 
http://www.csounds.com/manual/html/pcount.html

note that you have to use the '!' feature to prevent carry:


instr 1
icount pcount
print icount
endin


i 1 0 1 2 3
i 1 1 1
i 1 2 1 !



does this help?

	joachim





Am 16.04.2013 13:13, schrieb Mark Brophy:
> It's a pity that there is no reliable way to check for unprovided fields
> in an instrument. Will CSound 6 change this?
>
>
> On Tue, Apr 16, 2013 at 5:58 AM, Justin Smith  > wrote:
>
>     in the score, the first - + is only a shorthand for repeating the
>     previous increment in one column
>
>
>     On Tue, Apr 16, 2013 at 3:55 AM, Mark Brophy      > wrote:
>
>         I'm wondering what happens when the "+" is omitted, so if:
>         i1  0  0.5  100
>         i1  1.0 0.5
>         does that result in this?
>         i1  0  0.5  100
>         i1  1.0   0.5  100
>         or does it result in this?
>         i1  0  0.5  100
>         i1  1.0   0.5  0
>
>
>
>         On Tue, Apr 16, 2013 at 5:38 AM, Justin Smith
>         > wrote:
>
>             The score parser will repeat the last provided field. If
>             none was provided in a previous invocation, it becomes 0.
>
>             There is no reliable way to check for unprovided fields in
>             an instrument. You can of course check for 0 and provide a
>             default in that case.
>
>             To elaborate on an example from the manual:
>
>             the statements
>
>             i1   0    .5        100
>             i .  +
>             i
>
>             will result in
>
>             i1   0         .5        100 0
>             i1   .5        .5        100 0
>             i1   1         .5        100 0
>
>             for a 5 pfield instrument
>
>
>
>             On Tue, Apr 16, 2013 at 3:28 AM, Mark Brophy
>             > wrote:
>
>                 If I define an instrument with 8 p-fields and specify
>                 only 5 using an i-statement, how do I supply default
>                 values in the instrument for the unspecified fields?
>
>
>
>
>

Hi Jake,

Nice one!  I've been trying to figure recently if there isn't an
easier way to do this kind of thing.  The problem I see with either
your example or the one I had linked to is that they're a bit verbose,
IMO.  It's not a problem if a program generates the code to do the
chnget's and chnset's, but it's not so easy to read and understand by
looking at the code, especially as an instrument gets more and more
settings.

SuperCollider has the notion of SynthDef args, which are sort of nice
in that you can set them outside of the Synth instance.  This comes
closer I think, but isn't quite it either.  It's not really a shared
value between Synth instances unless you bind the arg to a ~var or
something like that, but it's sort of using features to support a
concept instead of having something built-in. (Sort of the same as
using channels to support instrument-wide settings in csound).

What seems more like what I'm thinking is what would be static
variables in Java, or something like class members in Python.  Maybe
something like:

instr 1

static
  _kattack init 0.02
  _kdecay init 0.01
  _ksustain init 0.95
  _krelease init 0.2
endstatic

kenv adsr i(_kattack), i(_kdecay), i(_ksustain), i(_krelease)
aout vco2 440, kenv
outs aout, aout

endin

where _ could designate an instrument scoped var, similar to how g
designates global. The static block could be used to initialize the
vars (i-time only code, run once after an instrument is defined). The
_ vars could then modified using something like "chnset 1, "kattack",
kline" (overriding chnset to have a form that takes in an instr id).
I guess this isn't so bad, but I'm not sure this is so great to look
at though either. :P

steven




On Tue, Apr 16, 2013 at 7:41 PM, Jacob Joaquin  wrote:
> I've also experimented much with this in the past, though the example I dug
> up connects modules in the score using a very convoluted system of doing it;
> Hard to read, even harder to debug when something went wrong. But similar
> idea in altering the state of an instrument independent from note events. It
> was part of The Csound Blog, so there's a writeup included in the code:
>
> https://gist.github.com/jacobjoaquin/5398335
>
> Audio:
> https://soundcloud.com/jacobjoaquin/the-csound-blog-modular
>
>
>
>
>
>
> On Tue, Apr 16, 2013 at 11:07 AM, Steven Yi  wrote:
>>
>> Hi All,
>>
>> Jake's example reminded of some instrument design thoughts I've had
>> and wanted to share, so I'm going a bit offtopic from Jake's offtopic.
>> :P
>>
>> Csound instruments can easily have per-note values, but having
>> per-instrument values can simplify instrument note design so that
>> instruments can be configurable but still be reused easily if they
>> share the same pfield signature.  This is common in MIDI instruments,
>> which all conform to the same event messaging protocol for per-note
>> values (i.e. pitch velocity), but have per-instrument values
>> configured via sysex/OSC/direct UI control, etc.
>>
>> I explored this a bit in:
>>
>> http://www.csounds.com/journal/issue13/emulatingMidiBasedStudios.html
>>
>> One can see it in the SawBody instrument, where chnget is used to read
>> the current value of a cutoff frequency for moogladder.  That value
>> can be changed independently of the note events.  Note the instr 1 and
>> instr 2 in the example, how they are used in the score to modify
>> configurable values for an instrument.
>>
>> In Blue, I often write things like i()  where  is a
>> gk-var value that blue generates.  This allows that when an instrument
>> instance starts, it will read the current value that is generated from
>> a knob or slider, and use that as the attack time to linsegr or adsr.
>> (I'm sure that users using Cabbage and CsoundQT probably end up doing
>> something similar)
>>
>> Anyways, a bit off-off-topic now, but just wanted to mention that.
>>
>> Thanks!
>> steven
>>
>>
>> On Tue, Apr 16, 2013 at 3:43 PM, Jacob Joaquin 
>> wrote:
>> > Off topic, though this is one of the issues I'm attempting to address
>> > with
>> > PythonScore. The idea is to allow composers to create simpler interfaces
>> > to
>> > instruments with lots of pfield arguments. For example, here are the
>> > pfields
>> > for a kick drum synth I'm working on:
>> >
>> > instr 2
>> >     p3 = p4
>> >     idur = p4
>> >     iamp = p5
>> >     ifreq1 = p6
>> >     ifreq2 = p7
>> >     itrans_dur = p8
>> >     itrans_amp = p9  * 0.5
>> >     itrans_freq = p10
>> >     itrans_lp = p11
>> >     ixfade = p12
>> >     ixfade2 = p13
>> >     ieq_amp = p14
>> >     ieq_freq = p15
>> >     ieq_reson = p16
>> >
>> >     ....
>> >
>> > That's a lot of input for a kick. A classical Csound score event looks
>> > something like this:
>> >
>> > i 2 0 1 0.1333 0.707 200 50 0.01 4 900 900 0.02 0.05 0.5 200 0.3
>> >
>> > There are multiple approaches in PythonScore for creating a cleaner
>> > interfaces to instruments loaded with pfield inputs. For example, this
>> > function only requires the start time, amplitude, and an option for the
>> > transient amp:
>> >
>> > def my_kick(start, amp, transient_amp=4):
>> >     score.i(2, start, 1, 0.1333, amp, 200, 50, 0.01, transient_amp, 900,
>> > 900, 0.02, 0.05,
>> >                 0.5, 200, 0.3)
>> >
>> > In use, it would look something like this:
>> >
>> > my_kick(0, 0.707, 6)
>> > my_kick(2, 0.707)
>> > my_kick(2.5, 0.707, 2)
>> >
>> > It would also be possible to create various other kicks using the same
>> > instrument, but with multiple PythonScore interfaces. Here's a very
>> > different sounding kick from the same instrument, but different
>> > function:
>> >
>> > def other_kick(start, dur, amp, transient_amp=4):
>> >     score.i(2, start, 1, dur, amp, 100, 50, 0.03, transient_amp, 8000,
>> > 1500,
>> > 0.04, 0.05,
>> >                 0.3, 75, 0.7)
>> >
>> > And they could be used together:
>> >
>> > my_kick(0, 0.707, 2)
>> > other_kick(2, 0.1, 0.707)
>> >
>> > Working this way is analogous to working with patches on a synth.
>> >
>> >
>> >
>> > On Tue, Apr 16, 2013 at 3:28 AM, Mark Brophy 
>> > wrote:
>> >>
>> >> If I define an instrument with 8 p-fields and specify only 5 using an
>> >> i-statement, how do I supply default values in the instrument for the
>> >> unspecified fields?
>> >
>> >
>> >
>> >
>> > --
>> > codehop.com | #code #art #music
>>
>>
>> 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

I use code generation in Blue; it works well enough and is effective.
It allowed building tools for automations, realtime modification of
instrument params, etc.  Fortunately, Csound has enough features
already that a great number of musical ideas can be expressed through
it, and made easier to do so with tools built on top of it.  On the
other hand, I still get the impression that there could be something
internal to Csound here that provides better building blocks for tools
to build upon. Anyways, probably time to give this off-off-topic a
rest and get back to other coding. :)  Looking forward to seeing what
you come up with with your Py score/orc explorations!

steven

On Tue, Apr 16, 2013 at 11:46 PM, Jacob Joaquin  wrote:
> At this point I personally favor code generation. I have some ideas on
> handle to handle this issue in Python, and even have some code written, but
> it's a more complex problem to solve than generating scores. Though I
> envision a future where there is less distinction between a PythonScore and
> a PythonOrchesta, where creating instrument like these are easier to write
> and easier to player.
>
>
> On Tue, Apr 16, 2013 at 2:32 PM, Steven Yi  wrote:
>>
>> Hi Jake,
>>
>> Nice one!  I've been trying to figure recently if there isn't an
>> easier way to do this kind of thing.  The problem I see with either
>> your example or the one I had linked to is that they're a bit verbose,
>> IMO.  It's not a problem if a program generates the code to do the
>> chnget's and chnset's, but it's not so easy to read and understand by
>> looking at the code, especially as an instrument gets more and more
>> settings.
>>
>> SuperCollider has the notion of SynthDef args, which are sort of nice
>> in that you can set them outside of the Synth instance.  This comes
>> closer I think, but isn't quite it either.  It's not really a shared
>> value between Synth instances unless you bind the arg to a ~var or
>> something like that, but it's sort of using features to support a
>> concept instead of having something built-in. (Sort of the same as
>> using channels to support instrument-wide settings in csound).
>>
>> What seems more like what I'm thinking is what would be static
>> variables in Java, or something like class members in Python.  Maybe
>> something like:
>>
>> instr 1
>>
>> static
>>   _kattack init 0.02
>>   _kdecay init 0.01
>>   _ksustain init 0.95
>>   _krelease init 0.2
>> endstatic
>>
>> kenv adsr i(_kattack), i(_kdecay), i(_ksustain), i(_krelease)
>> aout vco2 440, kenv
>> outs aout, aout
>>
>> endin
>>
>> where _ could designate an instrument scoped var, similar to how g
>> designates global. The static block could be used to initialize the
>> vars (i-time only code, run once after an instrument is defined). The
>> _ vars could then modified using something like "chnset 1, "kattack",
>> kline" (overriding chnset to have a form that takes in an instr id).
>> I guess this isn't so bad, but I'm not sure this is so great to look
>> at though either. :P
>>
>> steven
>>
>>
>>
>>
>> On Tue, Apr 16, 2013 at 7:41 PM, Jacob Joaquin 
>> wrote:
>> > I've also experimented much with this in the past, though the example I
>> > dug
>> > up connects modules in the score using a very convoluted system of doing
>> > it;
>> > Hard to read, even harder to debug when something went wrong. But
>> > similar
>> > idea in altering the state of an instrument independent from note
>> > events. It
>> > was part of The Csound Blog, so there's a writeup included in the code:
>> >
>> > https://gist.github.com/jacobjoaquin/5398335
>> >
>> > Audio:
>> > https://soundcloud.com/jacobjoaquin/the-csound-blog-modular
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Tue, Apr 16, 2013 at 11:07 AM, Steven Yi  wrote:
>> >>
>> >> Hi All,
>> >>
>> >> Jake's example reminded of some instrument design thoughts I've had
>> >> and wanted to share, so I'm going a bit offtopic from Jake's offtopic.
>> >> :P
>> >>
>> >> Csound instruments can easily have per-note values, but having
>> >> per-instrument values can simplify instrument note design so that
>> >> instruments can be configurable but still be reused easily if they
>> >> share the same pfield signature.  This is common in MIDI instruments,
>> >> which all conform to the same event messaging protocol for per-note
>> >> values (i.e. pitch velocity), but have per-instrument values
>> >> configured via sysex/OSC/direct UI control, etc.
>> >>
>> >> I explored this a bit in:
>> >>
>> >> http://www.csounds.com/journal/issue13/emulatingMidiBasedStudios.html
>> >>
>> >> One can see it in the SawBody instrument, where chnget is used to read
>> >> the current value of a cutoff frequency for moogladder.  That value
>> >> can be changed independently of the note events.  Note the instr 1 and
>> >> instr 2 in the example, how they are used in the score to modify
>> >> configurable values for an instrument.
>> >>
>> >> In Blue, I often write things like i()  where  is a
>> >> gk-var value that blue generates.  This allows that when an instrument
>> >> instance starts, it will read the current value that is generated from
>> >> a knob or slider, and use that as the attack time to linsegr or adsr.
>> >> (I'm sure that users using Cabbage and CsoundQT probably end up doing
>> >> something similar)
>> >>
>> >> Anyways, a bit off-off-topic now, but just wanted to mention that.
>> >>
>> >> Thanks!
>> >> steven
>> >>
>> >>
>> >> On Tue, Apr 16, 2013 at 3:43 PM, Jacob Joaquin 
>> >> wrote:
>> >> > Off topic, though this is one of the issues I'm attempting to address
>> >> > with
>> >> > PythonScore. The idea is to allow composers to create simpler
>> >> > interfaces
>> >> > to
>> >> > instruments with lots of pfield arguments. For example, here are the
>> >> > pfields
>> >> > for a kick drum synth I'm working on:
>> >> >
>> >> > instr 2
>> >> >     p3 = p4
>> >> >     idur = p4
>> >> >     iamp = p5
>> >> >     ifreq1 = p6
>> >> >     ifreq2 = p7
>> >> >     itrans_dur = p8
>> >> >     itrans_amp = p9  * 0.5
>> >> >     itrans_freq = p10
>> >> >     itrans_lp = p11
>> >> >     ixfade = p12
>> >> >     ixfade2 = p13
>> >> >     ieq_amp = p14
>> >> >     ieq_freq = p15
>> >> >     ieq_reson = p16
>> >> >
>> >> >     ....
>> >> >
>> >> > That's a lot of input for a kick. A classical Csound score event
>> >> > looks
>> >> > something like this:
>> >> >
>> >> > i 2 0 1 0.1333 0.707 200 50 0.01 4 900 900 0.02 0.05 0.5 200 0.3
>> >> >
>> >> > There are multiple approaches in PythonScore for creating a cleaner
>> >> > interfaces to instruments loaded with pfield inputs. For example,
>> >> > this
>> >> > function only requires the start time, amplitude, and an option for
>> >> > the
>> >> > transient amp:
>> >> >
>> >> > def my_kick(start, amp, transient_amp=4):
>> >> >     score.i(2, start, 1, 0.1333, amp, 200, 50, 0.01, transient_amp,
>> >> > 900,
>> >> > 900, 0.02, 0.05,
>> >> >                 0.5, 200, 0.3)
>> >> >
>> >> > In use, it would look something like this:
>> >> >
>> >> > my_kick(0, 0.707, 6)
>> >> > my_kick(2, 0.707)
>> >> > my_kick(2.5, 0.707, 2)
>> >> >
>> >> > It would also be possible to create various other kicks using the
>> >> > same
>> >> > instrument, but with multiple PythonScore interfaces. Here's a very
>> >> > different sounding kick from the same instrument, but different
>> >> > function:
>> >> >
>> >> > def other_kick(start, dur, amp, transient_amp=4):
>> >> >     score.i(2, start, 1, dur, amp, 100, 50, 0.03, transient_amp,
>> >> > 8000,
>> >> > 1500,
>> >> > 0.04, 0.05,
>> >> >                 0.3, 75, 0.7)
>> >> >
>> >> > And they could be used together:
>> >> >
>> >> > my_kick(0, 0.707, 2)
>> >> > other_kick(2, 0.1, 0.707)
>> >> >
>> >> > Working this way is analogous to working with patches on a synth.
>> >> >
>> >> >
>> >> >
>> >> > On Tue, Apr 16, 2013 at 3:28 AM, Mark Brophy 
>> >> > wrote:
>> >> >>
>> >> >> If I define an instrument with 8 p-fields and specify only 5 using
>> >> >> an
>> >> >> i-statement, how do I supply default values in the instrument for
>> >> >> the
>> >> >> unspecified fields?
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > codehop.com | #code #art #music
>> >>
>> >>
>> >> 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
>>
>>
>> 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