simplify union of bare values

[felixroos]

another value related thing that would be handy:

stack(
"0 1 2",
"7 10 11"
).scale('E minor').note()

The above snippet works, but what if I want to add a cutoff to the first pattern?

stack(
"0 1 2".cutoff(1000), // <---- this fails
"7 10 11"
).scale('E minor').note()

the only way to do this is to rewrite:

stack(
"0 1 2".scale('E minor').note().cutoff(1000),
"7 10 11".scale('E minor').note()
)

which means a lot of duplication and rearranging.. the duplication can be solved by

const h = x=>x.scale('E minor').note();
stack(
"0 1 2".layer(h).cutoff(1000),
"7 10 11".layer(h)
)

but that's not optimal.. It would be really convenient if the second snippet just worked.. here is it again:

stack(
"0 1 2".cutoff(1000), // <---- this fails
"7 10 11"
).scale('E minor').note()

The problem: "0 1 2".cutoff(1000) generates values like { value:0, cutoff: 1000}, which are then wrapped into note later, creating { note: { value:0, cutoff: 1000} } . A possible solution would be to check if a control value is an object containing a value, and if thats the case, just use the value and merge the rest on top level, giving: { note: 0, cutoff: 1000}. I don't see any drawbacks there, except that you cannot have objects as control values that contain the now protected "value" keyword.

[felixroos]

and if that is really a problem, we could rename "value" to "__value" or something like that

[yaxu]

Hmm I see the problem but find this solution a bit confusing, needs some more thought I think..

[felixroos]

I don't see any alternative.. having this would make live coding so much easier, I run into this problem all the time.

[yaxu]

One alternative would be:

stack(
note("0 1 2").cutoff(3000),
note("7 10 11")
).scale('E minor')

Advantages:

• you don't have to search through the pattern to find out what the "0 1 2" is
• less of a conceptual leap as you don't have to imagine adding an effect to a bare value
• scales better as the pattern gets more complex, it's clear what everything is

Disadvantage:

• a bit more to type in

The question is what 'scale' does. Either it adds another parameter and the synth decides what to do with it, or it manipulates the note values directly. In the latter case, it could make sense for it to be a bit polymorphic and work on both bare values and objects, in the latter case it looks for 'note' and works on that.

(I still think scale names should be identifiers, i.e. without spaces.)

[felixroos]

The question is what 'scale' does. Either it adds another parameter and the synth decides what to do with it, or it manipulates the note values directly. In the latter case, it could make sense for it to be a bit polymorphic and work on both bare values and objects, in the latter case it looks for 'note' and works on that.

(I still think scale names should be identifiers, i.e. without spaces.)

I guess that is now solved with #502

One alternative would be: .....

I agree to everything, but the feature in question doesn't take that away, as it just adds an alternative way to notate things. Also, it would unlock mini notation features that edit controls, such as #193 . If we don't do it, this way of notation will just produce a runtime error, so why not just allow it?

[felixroos]

this "feature" now has a poc here: #973 not sure if we should add it or not.. the upside is much more writing flexibility + terseness the downside is that it allows writing more confusing code

[felixroos]

#973 is now merged after discussion in discord