More Mixer Musings

[Steven Yi]

Hi All,

I'm posting this on the dev list as it's more implementation oriented.
 I am thinking that effects should generate as UDO's, and for the
editor you choose number of inputs and outputs (1 or more for each),
and those values are going to come in hardcoded ain1, ain2, etc. and
output as aout1, aout2, depending on num inputs/outputs set.  For
coding an effect, you only have to implement the code and not worry
about the UDO details.

I was beginning to think also that UDO's would have something like:

opcode echo

ain1, ain2, [list of values set from interface] xin

...code...

xout aout1, aout2
endop

So that we can reuse UDO's and send in parameters from the interface,
but I think it could be a headache and that there won't be *THAT* many
effects, and even if there were many, it wouldn't affect parsing too
much.

I am thinking that all effects though will be given autoassigned names
with the original name added as a comment to the output, something
like:

opcode bMixerEffect0 ; mixer effect: echo
...
endop

this is to avoid collision of effects names, and may play a part later
if we arm parameters for automation.

Just thought I'd throw this out there to see if this sounds good or
not.  I'm going to go ahead with this design when I start working
later tonight and can change later if other solutions or issues are
presented.

Thanks!
steven


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Bluemusic-devel mailing list
Bluemusic-devel@...
https://lists.sourceforge.net/lists/listinfo/bluemusic-devel

[day 5]

real time equalizer

<CsoundSynthesizer>
<CsInstruments>


sr = 44100
kr = 441
ksmps = 100
nchnls = 2
        zakinit 2, 2
        ctrlinit 1, 8, 40, 9, 40, 10, 40, 11, 16, 12, 40, 13, 40, 14, 40, 15,
16

#define SOUNDFILE # "/Volumes/Neuromancer/dc1/dc1-5.aif" #

/*=== ===*/

                opcode scale, k, kkk

kval, kmin, kmax xin

kscl = kval * (kmax - kmin) + kmin

        xout kscl

                endop

/*=== ===*/
; klvl = 1, flat
; klvl = 4, +12dB
; klvl = 0.1, -20dB

                opcode equalizer, aaa, akkkkkk

ain, klvl1, klvl2, klvl3, kq1, kq2, kq3 xin

alo rbjeq ain, 100, klvl1, kq1, 1, 10
amd rbjeq ain, 800, klvl2, kq2, 1, 8
ahi rbjeq ain, 8000, klvl3, kq3, 1, 12

        xout alo, amd, ahi

                endop

/*=== ===*/

                opcode denormk, k, k

ken xin

ain upsamp ken
        denorm ain
kout downsamp ain

        xout kout

                endop

;//--
/*---

                instr 1

ar0 phasor 1/(sr/ftlen(1))
ar0 = (ar0 * ftlen(1))

atbl table ar0, 1
atbr table (ftlen(1)-ar0), 1

atbl = atbl * 22200
atbr = atbr * 22200

        zaw atbl, 1
        zaw atbr, 2

                endin

---*/

                instr 1

al, ar diskin2 $SOUNDFILE, 1, 0, 1

        zaw al, 1
        zaw ar, 2

                endin

/*--- ---*/

                instr 2 ; klvl in range 0.025-3
                                ; for -26 to +9 dB range

klv1 ctrl7 1, 8, 0, 1
klv2 ctrl7 1, 9, 0, 1
klv3 ctrl7 1, 10, 0, 1
kqu1 ctrl7 1, 12, 0, 1
kqu2 ctrl7 1, 13, 0, 1
kqu3 ctrl7 1, 14, 0, 1

ktl ctrl7 1, 11, 0, 1
ktq ctrl7 1, 15, 0, 1

ktl scale ktl, 0.01, 0.618
klv1 portk klv1, ktl
klv2 portk klv2, ktl
klv3 portk klv3, ktl

ktq scale ktq, 0.01, 0.618
kqu1 portk kqu1, ktq
kqu2 portk kqu2, ktq
kqu3 portk kqu3, ktq

klvl1 scale klv1, 0.001, 8
klvl2 scale klv2, 0.001, 8
klvl3 scale klv3, 0.001, 8
kq1 scale kqu1, 0.1, 3
kq2 scale kqu2, 0.1, 3
kq3 scale kqu3, 0.1, 3

atbl zar 1
atbr zar 2

all, aml, ahl equalizer atbl, klvl1, klvl2, klvl3, kq1, kq2, kq3
alr, amr, ahr equalizer atbr, klvl1, klvl2, klvl3, kq1, kq2, kq3

amixl = (all+aml+ahl)/3
amixr = (alr+amr+ahr)/3

        outs amixl, amixr
        zacl 1, 2

                endin

/*--- ---*/

                instr 3 ; listen to the zak bus

al zar 1
ar zar 2

        outs al, ar
        zacl 1, 2

                endin

/*--- ---*/
</CsInstruments>
<CsScore>

i1 0 3600
i2 0 3600
;i3 0 3600

e
</CsScore>

</CsoundSynthesizer>


./d5

On Feb 27, 2006, at 6:17 PM, Steven Yi wrote:

> Hi All,
>
> I'm posting this on the dev list as it's more implementation oriented.
>  I am thinking that effects should generate as UDO's, and for the
> editor you choose number of inputs and outputs (1 or more for each),
> and those values are going to come in hardcoded ain1, ain2, etc. and
> output as aout1, aout2, depending on num inputs/outputs set.  For
> coding an effect, you only have to implement the code and not worry
> about the UDO details.
>
> I was beginning to think also that UDO's would have something like:
>
> opcode echo
>
> ain1, ain2, [list of values set from interface] xin
>
> ...code...
>
> xout aout1, aout2
> endop
>
> So that we can reuse UDO's and send in parameters from the interface,
> but I think it could be a headache and that there won't be *THAT* many
> effects, and even if there were many, it wouldn't affect parsing too
> much.
>
> I am thinking that all effects though will be given autoassigned names
> with the original name added as a comment to the output, something
> like:
>
> opcode bMixerEffect0 ; mixer effect: echo
> ...
> endop
>
> this is to avoid collision of effects names, and may play a part later
> if we arm parameters for automation.
>
> Just thought I'd throw this out there to see if this sounds good or
> not.  I'm going to go ahead with this design when I start working
> later tonight and can change later if other solutions or issues are
> presented.
>
> Thanks!
> steven

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Bluemusic-devel mailing list
Bluemusic-devel@...
https://lists.sourceforge.net/lists/listinfo/bluemusic-devel

[Steven Yi]

Hi day5,

I think the example you posted is in line with what I was going to
avoid for simplicity's sake of having control parameters be inputs
into the UDO.  I am planning on making it be values internally set
within the body of the code in the same way BSB is, as there are
issues invovled with name space clashing and versioning of effects.

Otherwise, what you have posted will certainly be possible to express
within the new effects system (minus the control signal automation, at
least in the initial version).

steven


On 2/27/06, day 5 <day5ive@...> wrote:

> real time equalizer
>
> <CsoundSynthesizer>
> <CsInstruments>
>
>
> sr              =       44100
> kr              =       441
> ksmps   =       100
> nchnls  =       2
>         zakinit 2, 2
>         ctrlinit        1, 8, 40, 9, 40, 10, 40, 11, 16, 12, 40, 13, 40, 14, 40, 15,
> 16
>
> #define SOUNDFILE       # "/Volumes/Neuromancer/dc1/dc1-5.aif" #
>
> /*=== ===*/
>
>                 opcode  scale, k, kkk
>
> kval, kmin, kmax        xin
>
> kscl    =       kval * (kmax - kmin) + kmin
>
>         xout    kscl
>
>                 endop
>
> /*=== ===*/
> ; klvl = 1, flat
> ; klvl = 4, +12dB
> ; klvl = 0.1, -20dB
>
>                 opcode  equalizer, aaa, akkkkkk
>
> ain, klvl1, klvl2, klvl3, kq1, kq2, kq3 xin
>
> alo     rbjeq   ain, 100, klvl1, kq1, 1, 10
> amd     rbjeq   ain, 800, klvl2, kq2, 1, 8
> ahi     rbjeq   ain, 8000, klvl3, kq3, 1, 12
>
>         xout    alo, amd, ahi
>
>                 endop
>
> /*=== ===*/
>
>                 opcode  denormk, k, k
>
> ken     xin
>
> ain     upsamp  ken
>         denorm  ain
> kout    downsamp        ain
>
>         xout    kout
>
>                 endop
>
> ;//--
> /*---
>
>                 instr   1
>
> ar0     phasor  1/(sr/ftlen(1))
> ar0     =       (ar0 * ftlen(1))
>
> atbl    table   ar0, 1
> atbr    table   (ftlen(1)-ar0), 1
>
> atbl    =       atbl * 22200
> atbr    =       atbr * 22200
>
>         zaw     atbl, 1
>         zaw     atbr, 2
>
>                 endin
>
> ---*/
>
>                 instr   1
>
> al, ar  diskin2 $SOUNDFILE, 1, 0, 1
>
>         zaw     al, 1
>         zaw     ar, 2
>
>                 endin
>
> /*--- ---*/
>
>                 instr   2       ; klvl in range 0.025-3
>                                 ; for -26 to +9 dB range
>
> klv1    ctrl7   1, 8, 0, 1
> klv2    ctrl7   1, 9, 0, 1
> klv3    ctrl7   1, 10, 0, 1
> kqu1    ctrl7   1, 12, 0, 1
> kqu2    ctrl7   1, 13, 0, 1
> kqu3    ctrl7   1, 14, 0, 1
>
> ktl     ctrl7   1, 11, 0, 1
> ktq     ctrl7   1, 15, 0, 1
>
> ktl     scale   ktl, 0.01, 0.618
> klv1    portk   klv1, ktl
> klv2    portk   klv2, ktl
> klv3    portk   klv3, ktl
>
> ktq     scale   ktq, 0.01, 0.618
> kqu1    portk   kqu1, ktq
> kqu2    portk   kqu2, ktq
> kqu3    portk   kqu3, ktq
>
> klvl1   scale   klv1, 0.001, 8
> klvl2   scale   klv2, 0.001, 8
> klvl3   scale   klv3, 0.001, 8
> kq1     scale   kqu1, 0.1, 3
> kq2     scale   kqu2, 0.1, 3
> kq3     scale   kqu3, 0.1, 3
>
> atbl    zar     1
> atbr    zar     2
>
> all, aml, ahl   equalizer       atbl, klvl1, klvl2, klvl3, kq1, kq2, kq3
> alr, amr, ahr   equalizer       atbr, klvl1, klvl2, klvl3, kq1, kq2, kq3
>
> amixl   =       (all+aml+ahl)/3
> amixr   =       (alr+amr+ahr)/3
>
>         outs    amixl, amixr
>         zacl    1, 2
>
>                 endin
>
> /*--- ---*/
>
>                 instr   3       ; listen to the zak bus
>
> al      zar     1
> ar      zar     2
>
>         outs    al, ar
>         zacl    1, 2
>
>                 endin
>
> /*--- ---*/
> </CsInstruments>
> <CsScore>
>
> i1      0       3600
> i2      0       3600
> ;i3     0       3600
>
> e
> </CsScore>
>
> </CsoundSynthesizer>
>
>
> ./d5
>
> On Feb 27, 2006, at 6:17 PM, Steven Yi wrote:
>
> > Hi All,
> >
> > I'm posting this on the dev list as it's more implementation oriented.
> >  I am thinking that effects should generate as UDO's, and for the
> > editor you choose number of inputs and outputs (1 or more for each),
> > and those values are going to come in hardcoded ain1, ain2, etc. and
> > output as aout1, aout2, depending on num inputs/outputs set.  For
> > coding an effect, you only have to implement the code and not worry
> > about the UDO details.
> >
> > I was beginning to think also that UDO's would have something like:
> >
> > opcode echo
> >
> > ain1, ain2, [list of values set from interface] xin
> >
> > ...code...
> >
> > xout aout1, aout2
> > endop
> >
> > So that we can reuse UDO's and send in parameters from the interface,
> > but I think it could be a headache and that there won't be *THAT* many
> > effects, and even if there were many, it wouldn't affect parsing too
> > much.
> >
> > I am thinking that all effects though will be given autoassigned names
> > with the original name added as a comment to the output, something
> > like:
> >
> > opcode bMixerEffect0 ; mixer effect: echo
> > ...
> > endop
> >
> > this is to avoid collision of effects names, and may play a part later
> > if we arm parameters for automation.
> >
> > Just thought I'd throw this out there to see if this sounds good or
> > not.  I'm going to go ahead with this design when I start working
> > later tonight and can change later if other solutions or issues are
> > presented.
> >
> > Thanks!
> > steven
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Bluemusic-devel mailing list
> Bluemusic-devel@...
> https://lists.sourceforge.net/lists/listinfo/bluemusic-devel
>

-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Bluemusic-devel mailing list
Bluemusic-devel@...
https://lists.sourceforge.net/lists/listinfo/bluemusic-devel

[Michael Bechard]

--- Steven Yi <stevenyi@...> wrote:

> ...
> I was beginning to think also that UDO's would have
> something like:
>
> opcode echo
>
> ain1, ain2, [list of values set from interface] xin
>
> ...code...
>
> xout aout1, aout2
> endop
>
> So that we can reuse UDO's and send in parameters
> from the interface,
> but I think it could be a headache and that there
> won't be *THAT* many
> effects, and even if there were many, it wouldn't
> affect parsing too
> much.
>

I'm not quite sure I follow. One can resuse
instruments, too, and send in interface parameters to
them via instrument params (p3, p4, etc.), so what's
the advantage (aside from the ability to set ksmps
separately)? And I wouldn't be too sure about people
not having too many effects. I like effects and plan
to use them liberally, if and when I get back into
csound.

> I am thinking that all effects though will be given
> autoassigned names
> with the original name added as a comment to the
> output, something
> like:
>
> opcode bMixerEffect0 ; mixer effect: echo
> ...
> endop
>
> this is to avoid collision of effects names, and may
> play a part later
> if we arm parameters for automation.
>

Sounds smart.

Michael Bechard


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Bluemusic-devel mailing list
Bluemusic-devel@...
https://lists.sourceforge.net/lists/listinfo/bluemusic-devel