RFC: new mapping annotations

[ghost]

Hey @gleb812 @zappfinger!

I was thinking about printing the human-readable names for the parameters. And I think I know a way to do this. My proposal is to change the format of annotations and make them more convenient. Check the full text: https://github.com/gleb812/pch2csd/wiki/UDO-annotations

First, ditch ;@ args. And replace it with two separate ;@ ins and ;@ outs. Second, add human-readable aliases for ;@ map.

Here is an example:

;@ map Amp s LinLogSwitch LVLamp CLAEXP 
;@ map LinLogSwitch d BUT002

;@ ins k:In
;@ outs k:Out
opcode LevAmp,0,iiii
  iKnob, iScale, izIn, izOut xin
  iMult = iKnob  ; TODO properly implement logarithmic mapping
  kIn zkr izIn
  zkw kIn*iMult
endop

;@ ins a:In
;@ outs a:Out
opcode LevAmp,0,iiii
...
endop

Let’s break it down into parts.

;@ map Amp s LinLogSwitch LVLamp CLAEXP 
;@ map LinLogSwitch d BUT002

So right after map we have a human-readable name for the parameter. Also check how the s map now refers to such name instead of an index.

;@ ins k:In
;@ outs k:Out
opcode LevAmp ...

So now we can annotate inlets and outlets with readable names too. Multiple ins and outs may look like this:

;@ ins a:In k:EnvMod k:LfoMod
;@ outs a:Out
opcode ...

What do you think about this?

[ghost]

The thing is that ;@ args provides us with a number of parameters which is redundant because we have maps.

And have to admit, maybe annotating ins and outs with names was too much :) Can replace them with something like ;@ in-out kkkk aaaa or ;@ in-out k k k k, a a a a

[gleb812]

@ech2 Well, I like it. At least ;@ in ;@ out parts..

[zappfinger]

Great idea. The examples are a bit confusing though, because I do not see (k)Amp or (k)LinLogSwitch being /used/ anywhere in the template...

BTW, about the modes: I have read somewhere that Clavia has 2 sorts of oscillators. The more memory expensive ones use parameters only - the can be changed in real-time. The 'mode' ones are using less memory, but they have to be saved ('compiled').

Richard

On 08/03/18 18:15, Eugene Cherny wrote:

Hey @gleb812 https://github.com/gleb812 @zappfinger https://github.com/zappfinger!

I was thinking about printing the human-readable names for the parameters in patch development. And I think I know a way to do this. My proposal is to change the format of annotations and make them more convenient. Check the full text: https://github.com/gleb812/pch2csd/wiki/UDO-annotations

First, ditch |;@ args|. And replace it with two separate |;@ ins| and |;@ outs|. Second, add human-readable aliases for |;@ map|.

Here is an example:

;@ map Amp s LinLogSwitch LVLamp CLAEXP ;@ map LinLogSwitch d BUT002

;@ ins k:In ;@ outs k:Out opcode LevAmp,0,iiii iKnob, iScale, izIn, izOutxin iMult= iKnob; TODO properly implement logarithmic mapping kInzkr izIn zkw kIn*iMult endop

;@ ins a:In ;@ outs a:Out opcode LevAmp,0,iiii ... endop

Let’s break it down into parts.

;@ map Amp s LinLogSwitch LVLamp CLAEXP ;@ map LinLogSwitch d BUT002

So right after |map| we have a human-readable name for the parameter. Also check how the |s| map now refers to such name instead of an index.

;@ ins k:In ;@ outs k:Out opcode LevAmp ...

So now we can annotate inlets and outlets with readable names too. Multiple ins and outs may look like this:

;@ ins a:In k:EnvMod k:LfoMod ;@ outs k:Out opcode ...

What do you think about this?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gleb812/pch2csd/issues/11, or mute the thread https://github.com/notifications/unsubscribe-auth/AFkYZxsMV4UztylKsEVZ09ArtGs2TeN9ks5tcWcZgaJpZM4SjCBJ.

[ghost]

Thanks guys. I’ll try to do something about this soon.

@zappfinger Well, Amp and LinLogSwitch are just aliases. You can use these names in ;@ map s and they can be printed with the -m keyword. It’s a kind of idea to document modules while programming them instead of using a separate XML file.

But nothing prevents you from using these names for variables as well — even better this way :)

BTW, about the modes

Thanks, I didn’t know about this!

[zappfinger]

I've read about it here (in the 'Polyphony and DSP usage' section):https://www.soundonsound.com/reviews/clavia-nord-modular-g2

a nice article, BTW....

On 08/03/18 18:49, Eugene Cherny wrote:

Thanks guys. I’ll try to do something soon about this.

@zappfinger https://github.com/zappfinger Well, Amp and LinLogSwitch are just aliases. You can use these names in |;@ map s| and they can be printed with the |-m| keyword. It’s a kind of idea to document modules while programming them instead of using a separate XML file.

BTW, about the modes

Thanks, I didn’t know about this!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gleb812/pch2csd/issues/11#issuecomment-371567010, or mute the thread https://github.com/notifications/unsubscribe-auth/AFkYZ7shXhPRjhdQSbTwOoeJWY9UI3skks5tcW8WgaJpZM4SjCBJ.

[ghost]

Hi guys. I think with https://github.com/gleb812/pch2csd/commit/35f26749f27159f61c52e7c5b28ff1b4d18bf750I, pushed more or less stable version of the work on new annotations. For a quick an lean example of how they look like, check 81.txt.

Changes:

• ;@ maps: it’s mossible now to assign names to maps. These names can be used to refer to another map in switch-map annotations (keyword s). Also, these names can be pretty-printed with the -m keyword.
• ;@ args was replaced with ;@ ins and ;@ outs as more readable solution.
• ;@ modes are now used to explicitly add modes.

For the full info, please read: https://github.com/gleb812/pch2csd/wiki/UDO-annotations

Please, check how it how everything is working now.

And here is the pretty-printing example:

$ pch2csd -m 4 voice tests/resources/test_LevAmp.pch2
Patch: tests/resources/test_LevAmp.pch2
Module LevAmp, type=81, id=4

Name          Type    Raw    Mapped
------------  ------  -----  --------
Amp           param   83     0.707
LinLogSwitch  param   1      1
In            inlet
Out           outlet

[ghost]

Hey @gleb812 @zappfinger,

Have you already tried using new annotations? Do they work fine?

[gleb812]

Hi! Me not yet.

[ghost]

@gleb812 could you check if the conversion of the test patches you’ve created before works fine?

[gleb812]

Ok, I will do it this weekend, once back from Moscow

[ghost]

I close this assuming everything works fine.