Meta Morph ... a new beginning

[NothanUmber]

Good question. I am also exclusively using chromatic tuning with lights on roots. (Edit: at least on Alpha, on Pico I sometimes used diatonic to trade accents for range)
That said, a scaler and led module sounds like a good idea!

I like the idea with the config file from which scales or light patterns can then be selected in the UI.
Perhaps one could use cent instead of semitones, so one could also experiment with non-western tunings?
So for scales it could look like this

scales:
chromatic: 0, 100, 200, 300, 400, 500, 600, 700, 800, 900, 1000, 1100
major: 0, 200, 400, 500, 700, 900, 1000
minor: 0, 200, 300, 500, 700, 800, 1000

For the led-module one could either define colors per scale degree. Which would mean one would need different patterns for e.g. 7 tone scales (like diatonic) or 12 tone scales (like chromatic) to color a “fifth”:

light patterns:
root-only: 1:green
diatonic-root-and-fifth: 1:green, 5:blue
chromatic-root-and-fifth: 1:green, 8:blue

Alternatively a certain cent delta or even a range of cent deltas could be defined to have a certain color.

light patterns:
root-only: 0-0:green
root-and-fifth: 0-0:green, 700-700:blue

This is assuming that the UI for both scaler and leds would additionally allow to define a root note (midi note number plus perhaps also a “tuning” cent value) - and the scale degrees or cent deltas in the patterns are relative to that.

Edit: The reverse mapping could in these cases be derived from the same specification. (Would need to revert the physical to musical mapping also though, so then leds would have to be implemented in the scaler again as long as no keygroups expose that mapping(?))

Or just with physical key positions as in your proposal. Colors wouldn’t follow transposition or scale changes etc. then but one can paint nice ascii art christmas trees that translate 1:1 into illuminated key trees
Would be all I would need personally.

horizonal-3-c1-root-fifth:
r - - - -
- - - - -
- g - - -
- - - - -
r - - - -

Edit: What is the input to the scaler or led module? Key numbers? Was thinking about where e.g. the functionality of a fingerer module could be implemented later on (which I was using for the Pico). I guess this shouldn’t go into the scaler but could be a separate module that is used together with/indead of the scaler?

[thetechnobear]

yeah, the idea is I will have (at this stage) simple scale lighting (basically 3 intervals in scale)
and then ‘custom’ which is physical not scale based.
this covers most use-cases imho.

if we consider that custom is most useful on tau/alpha … as they have more keys
… but, these are also where chromatic is mostly used.

basically having messed with leds over time, I tend to find less is more.
and also that repeating patterns of leds dont work very well on the alpha/tau - it loos a bit ‘fussy’.

I expect for many of us we end up using
pico: diatonic scales w/ root led
tau/alpha : chromatic w/ custom leds

why?
pico : few keys favours diatonic scales, and more than 1 led per octave looks a bit much.
tau/alpha : chromatic so we can play any scale and accidentals, having repetitive scale patterns, looks a bit much over large surface.

anyway we will see

[GoneCaving]

OK, so my 2c on lights. In terms of Alpha, for note keys it’s very usually chromatic with tonic and fifths. However, one good example of a very alternative layout was the layout that Geert used with the Sonic Couture Hang Drum VST. I could imagine a similar approach with VCV, where groups of keys have the same note but with variations on the modulation inputs. But I’m getting ahead of myself

Anything else above the chromatic is kinda of a nice to have in my opinion, but I could imagine, for example, a custom microtonal scale with a more complex light pattern, though I guess you’re still likely only needing tonic plus one or two other notes in the scale.

The static file approach for, I’m assuming, functional keys, makes sense, and the proposed format looks simple and flexible enough.

One final thought. In terms of the example patches, it might be worth considering adding one or two using a more expanded set of free modules, eg. the Befaco ones?

[keymanpal]

@GoneCaving

only needing tonic plus one or two other notes in the scale.

I’m with same thoughts overall, tonic+fifth gets more use for me.

[thetechnobear]

ok, scaler done … went a slightly different direction

Scaler module now supports Scala (scl) files for scales.
perhaps a bit overkill… but hey, why invent a new scale file format when there is a standard.

I might need someone with some more extensive scala experience to test some more esoteric scales - but for the ones I know it’s working well enough.
we also have the ability to set 3 different ‘degree leds’ with green, red or orange.

now I just need to do the custom led module
then I want to update EigenLite to a new api, and incorporate that into MetaMorph.

neither should be particularly difficult, as Ive a good idea what I want to do.

@GoneCaving

One final thought. In terms of the example patches, it might be worth considering adding one or two using a more expanded set of free modules, eg. the Befaco ones?

for demo and testing, unfortunately not…
the issue is, vcv has no way to ‘auto subscribe’ to modules if you are missing any.
so a user only knows they are missing something as it doesn’t work.
sure, you could tell them in a README… but we all know how many users read those

that said, we can share vcv patches here, or on patch storage… and use what we like for that.

BUT, I do want to make sure with Early Access, that I can get some help with the demo/tutorial/test ones.

Oh, and there is one other important note for development (for me)
the debug version of vcv rack (the one I compile/debug with) cannot use ‘downloaded modules’.
which means for me to use patches with Befaco modules in my dev environment, Id have to build these.
(and I don’t really want to get into that!)

tl;dr; everyone is free, obviously, to use whatever other modules they want… but for the ‘out of the box’ experience we’ll want it to be VCV Free vanilla

[GoneCaving]

@thetechnobear

for demo and testing, unfortunately not

Ok, the reasons make sense. Maybe a link to a thread here for additional patches?

[thetechnobear]

yeah, when I come to release the early access version - I’ll create a number of topics covering things like user guide, dev guide, demo/preset patches etc. basically, I’ll provide the ‘starting point’ for each.

the hope is, the EA community will help flesh these out to make ready for full release.
thus, allowing me to focus more on development (resolving issue/bugs etc)
as it always surprising how much time these ‘ancillary’ tasks actually take, and eat into dev time.

also… ‘engagement’ is also a really good way to focus efforts, and move this to the next level

[thetechnobear]

the illuminator is done

led patterns are stored in separate files , in a patterns directory.
(to kind of mirror the way Im doing scales’

they are a json format…
example file:

{
    "green"  :  [
        [1,1],
        [5,1],
        [9,1],
        [13,1],
        [17,1],
        [21,1],
        [25,1]
    ],

    "red"  :  [
        [3,1],
        [7,1],
        [11,1],
        [15,1],
        [19,1],
        [23,1]
    ],
    "orange"  :  [
        [3,3],
        [7,3],
        [11,3],
        [15,3],
        [19,3],
        [23,3]
    ]
}

so for each colour, we have an ‘array’ of row/column pairs, specified as 1…N, 1…N
so the above gives us a pattern like

G----
-----
R-O--
-----
G----
-----
R-O--
-----
G----
-----
R-O--
-----

note:
the pattern is ‘relative’ to the key group, and will ignore values outside its size
so the above will work on alpha, tau and pico.
though, of course, the pico we’d get

G-
--
R-
--
G-
--
R-
--

one thing Im ‘undecided on’ , which I’ll likely do in alpha phase.

key on/off lighting
currently, the pattern is static
this works on tau/alpha as firmware lights the orange button on touch.
but I don’t think this happens on Pico.
however: I may decide this is a function of the ‘Device’ module or even EigenApi
so that the Pico behaves the same as other eigenharps, and so does not need special treatment.
(e.g. its a bit of pain for every module to retain led state so it can revert on key off)

ok, now on to the EigenApi re-work

[keymanpal]

@thetechnobear

they are a json format…

Looking great for sure useful!

[thetechnobear]

OK… so EigenLite dev work is done, and integrated into Meta Morph.
… and its looking better than ever

the observant will notice that means dev work is done for the Early Access.

left to do:

• I plan to do a bit more testing (more general than ‘module level’)
• I’ve got a couple of ‘known’ minor issues, which I now need to either address or document.
• I want to prepare some documentation and demo/test patches for setting up the early access.

depending on how much extra testing, and what I find , this should be pretty quick - esp. as Ive (obviously) been testing modules as I go along.

the only assumption is, I don’t decide I want to add extra modules to simplify things further…but I think I probably have enough to get us started, and we can go from there.

[thetechnobear]

Q. is YOUR pico under reporting max PRESSURE values?

during testing today, Ive noticed that the pico appears to be reporting a max pressure of around 75%.
i.e. you expect a range of 0…4095 its more like 0…3192.
(whereas my tau is reporting 100%, 4095)
Ive just tested in EigenD (using my T3D module) and that appears to show the same thing.

and its seems consistent, so it looks to be an oddity… (that I want to eliminate !)

can someone look at values of PRESSURE from their pico
you can use midi outputs (look to see if it does to 100 or 127) or OSC.

(preferably then do same test on alpha/tau to check that you are seeing full response there)

IF this is happening for all users, then Im going to compress the signal to full range.

bare in mind ‘full pressure’ should be attainable without making your fingers bleed

note: Im not too worried about reporting 98-100% , thats ok, but below about 95% id see as undesirable.

[keymanpal]

@thetechnobear

can someone look at values of PRESSURE from their pico

I’ll do it later tonight (at the moment in the Theather )

[NothanUmber]

I get these value ranges with the “Experimental Setups->pico->MIDI Basic” standard Pico setup:
velocity: 1-127
pitch bend (x): 172-16194
mod-wheel (y): 0-127
poly-aftertouch: 0-100 on most keys and e.g. 0-95 on others (with some values in the history before the key is fully pressed down up to 115 - the highest value is above 100 even for the keys that end up with 9x).

[thetechnobear]

@NothanUmber

poly-aftertouch: 0-100 on most keys and e.g. 0-95 on others (with some values in the history before the key is fully pressed down up to 115 - the highest value is above 100 even for the keys that end up with 9x).

ok, thats pretty much inline with what Im seeing !
(do you have access to your Alpha, as I think that should be ‘full range’ , or at least closer to 98%)

0-100 on most keys - so that about 78% which is what Im getting…

0-95 on other , so that around 74% this is interesting too.
I’ve just noticed ONE of my pico keys is reporting about 85% of the others.
by tilting it to each axis, Ive determined which sensor is under-reporting (Y+), basically if you are down on one axis, then the max of total pressure will drop… goes back to my investigations into calibration.

ok, we should not get stressed about this… we have never noticed before…

the only reason, Ive noticed, is Im checking carefully that my code is correct, so looking for oddities.
also ‘unfortunately’ (fro those tending towards obsession), VCV reports accurate voltages and has scopes - which means its very easy for us to see when keys are not reacting as we expect.
probably best not too look… just in case you see something you’d prefer not to know!

anyway… assuming @keymanpal sees similar numbers, then Im going to compress the range, so that we get 100% at max pressure.
(Im currently testing this, and it does feel better, and more consistent with Tau)

funny Ive noticed EigenD is already doing similar for yaw/roll, by default it only uses about half the range of moment… which has kind of surprised me.

[keymanpal]

wow… when did this changed? was it like this from the start?
(PP value decreases as we go PB…)

Also used “Experimental Setups->pico->MIDI Basic

Both Silver Pico (older one and another one)

All keys are like this

Black Pico (lately most used)

All keys are like this

Later test with the Alpha, got to run.

[thetechnobear]

thanks @keymanpal , same as @NothanUmber and I , so I think we can say this is ‘normal’

my testing with Tau shows they will be 95-100%, so Id guess 120-127 in midi terms -so does not need this extra compression.

note: there will be some variants between eigenharps and even between keys, this is ‘normal’

also Id say overall its probably better to slightly over compress, so reach 100% slightly before full depression, than under and not be able to reach 100%.
in fact what Ive noticed is (on roll/yaw) is over compressing makes the touch feel much lighter, which in some ways feels better.

ANYWAY… I think we have a good starting point, once I release to EA , and users try it for themselves, and we can adjust with more feedback. ( * )

anyway. spent most of yesterday on this… need to move on to other testing !

---

( * ) I know some will say ‘make it configurable’, but I want to make it feel right ‘out of the box’.
most won’t ever adjust it…
e.g. in EigenD you can adjust this… how many can tell me how you do this?
hint: there is a bug in the code in this area, that Ive never seen reported

[thetechnobear]

ok, I think we are nearly there…

yesterday,
I created most of the documentation that I want in place,
adjusted feel, particularly, the pico

today,
Ive created a demo patch for each eigenharp, these are basically the same, but adjusted for layout.
this also helped me test most of the modules again, in a broader context.
done a lot of ‘polishing’, so that the modules have less quirks and a few QoL changes. aka, clearing most of my known issues/todo lists.

so pretty much ready to go.
tomorrow I plan to film a video, which’ll cover the release and how to use the modules etc.
from there I just need to prep the EA release !

could be released anything from tomorrow evening till the weekend…
really depends on the video filming, and more importantly editing time… which can take many hours.
but its an important stage, so users will know how to use what Im releasing!

[keymanpal]

@thetechnobear

in EigenD you can adjust this… how many can tell me how you do this?

Ajusting scale 1.0 > to 1.4 gives 1-127

@thetechnobear

there is a bug in the code in this area, that Ive never seen reported

ummm now you have to mention it eheh

-.-.-.-.-.-

Alpha keys (same Experimental Setup )=
between 115 and 127, most of them around 120/125

[thetechnobear]

Nope… that scales the output, it’s not changing how the eigenharp raw data is being compressed.
Hint: only roll and yaw are being compressed

Alpha, cool, that’s in line with what I’ve seen on tau - seems to be a pico firmware issue.

[keymanpal]

@thetechnobear

Hint: only roll and yaw are being compressed

ok, maybe workbench… keyboard or key group? (although changing some values did not change much ;-(