Meta Morph ... a new beginning

Eigenharp
21

so after a bit of a break… Im getting back to this, as Id like to get some kind of beta/early access out there…

however, there is one thing I need to tidy up before this EA release - nomenclature

tl;dr; what nomenclature (and abbreviations) should we use on modules for axis and key position?
(see below for options, explanations)

this is very important, since as I create more modules it becomes an increasing burden if I want to change… so I want to get it right first time !

lets review …

EigenD

  • row/column - for ‘key’ position
  • roll (pitch) , yaw (timbre), pressure

common in MPE

  • x (pitch) , y (timbre), z (pressure)

it doesn’t really have a ‘key position’ , but things like linnstrument I believe use row/column.

others

ok, there are others like slide/glide/tilt, and things like timbre but these don’t really feel generic enough, or relevant to the eigenharp, and I don’t want to create my own terms either… enough confusion already !
note: I really do not want to use timbre/pitch, as x/y can be used for alternative use-cases.

summary, if we don’t want x,y,z , then Id go for existing eigend terms (roll, yaw, pressure)

where we are now…

MetaMorph

  • x (pitch) y (timbre) z (pressure) for axis
  • row/col for key position.

note: I will need to use R/C as abbreviations for row/column in certain UI elements, though will have tooltips to expand to explain.

this has a couple of oddities
a) in maths (etc) Y is the vertical axis … not horizontal!
b) I do want to create a module which rotates areas, so row → column, column->row

(a) is most ‘concerning’ … and I cannot switch y to be pitch, as that’ll be more confusing.
(b) is not really an issue, but its just a bit odd … I mean if you do x->y, y->x is not really any clearer !

alternative?

this did have me thinking perhaps switching to roll/yaw/pressure. (hence this post!)
BUT that also is problematic…
first , we can’t use abbreviation - (R)oll and (R)ow, thats a big issue.
second, I dont think the terms roll and yaw, mean much to users… unless familiar with eigend. its not immediately obvious which is which.

so whilst its ok in EigenD, I’m not that convinced to switch … which I guess is why I chose x,y,z when in the first place when coding … but that Y = horizontal axis is bugging me :slight_smile:

I could switch to Y(pitch) X (timbre), but I suspect that’d be more confusing, unless you are into maths.

so, I think likelihood is I’ll leave as Ive got it, and sort out the consistency… but be very useful to get some feedback.

thoughts? ideas? suggestions?

2 Likes
22

It seems the way it is! as no real better option…

1 Like
23

oh, another thing…

early access volunteers

for the early access, Id actually like to work with a few (2 or 3?) people closely, so that the official beta will be easier to support.

to do this, you’d have to be able to supply a bit of ‘time’ on the project (not too much )
and as you’ll see… it’ll be fun… it just helps me focus more on dev.

what does it involve?

3 things :

1) testing

between us we need to test ALL eigenharps ( pico, alpha , tau)
you’ll be coming in with little documentation… so have to learn on your feet .

2) demo patches

between us, we would create some demo patches which will for each eigenharp, that’ll will demonstrate how to use each module - that we could ship with release.

notes:

  • demo patches must only use vcv free ‘factory’ modules, so it works on a fresh vcv install without other modules.
  • some demo patches we will need variants for eigenharp models, due to keys layout etc.
  • it be useful to include a note module to roughly describe patch, you can also ‘take credit’ :slight_smile:
  • patches need to be ‘tidy’, so others can follow whats going on.

3) documentation

help with documentation, perhaps we will start a wiki page on this discord ?!

what its not

though, Im happy to hear suggestions (and obviously bugs) , I do not want feature requests (at this time) - Ive lots of plans, and I don’t want to start building up a massive to do list.

once we are in beta, we will discuss (as a community) , future plans, and also how we can split feature requests into various modules so that, perhaps, other community developers can get involved.

so really , its not much more than playing/testing with meta morph, but just with a bit more focus.
we will coordinate this on this forum, on a separate topic, including answering questions

mid term participation to project

there are two other ways the community can get involved, which are perhaps post beta…

a) graphic design
Ive a lot on my plate (and this is not my area of expertise) so the module graphics are not great.
the actual module graphics are all held in SVG files which you can edit with Inkscape.
if someone would like to get involved, and improve these… we could work together on this.
(I can explain whats needed, limitations to changes etc)

b) module development
one of the most exciting parts of this project is other developers can develop new modules to work with Meta Morph, whilst not requiring access (nor need to understand) the Meta Morph codebase, nor understand how it all works. this simplifies development considerably.
(also I’ll say developing VCV modules is pretty straightforward)

if anyone would like to get involved in this, then we can coordinate this on the forum.

2 Likes
24

I don’t have a concrete proposal, but in my mind it would be most helpful to the user if we could find names that capture the row-roll and column-yaw associations, because that’s the thing I have top of mind when configuring: row bends and column bends. How to distill that into a single character is still the puzzle.

(Aside: having lived my life in maths and engineering I think I’m less bothered by x/y selection than you; after all, it’s the player’s business how they hold their head, and the x axis often becomes f or t as appropriate. Then again, this applies more to the rows and the columns than to the key axes—it’s the row axis that’s most likely to be t in a sequencer layout or f when thinking chordally, and is overall the most natural choice for ‘independent’ axis. My best guess at what a mathematician would have done would be to call row 𝑥, column 𝑦, roll 𝜃, yaw 𝜙, and pressure 𝑧!)

1 Like
25

yeah, but introducing yet more terms might make it even more confusing, and I dont want to get too ‘mathematical’ about it .
(I remember being a bit ‘meh’ when Roli started using Slide/Glide/Strike etc )

Im not so worried about using x/y/z with row/col, thats ok… its just they are inconsistent :slight_smile:
if we want consistent, Id have to reverse one of them…

though, I cannot see anyone looking at a pico and saying it has 2 rows and 9 columns.
(well except me, as I mostly play it on a desk in that orientation… but perhaps pico is bad example!)

so that means reversing x/y… but Y is ingrained as timbre, ,as most expressive grids, keyboards, continuum have a horizontal orientation… so Y became CC74/timbre.

(Id almost say of the two… switching row/column is more natural… column = long axis?)

arghhh… Im back to square one.
which is this kind of practical trade off between technical correct vs common usage

perhaps Im overthinking
perhaps its better to leave as is… and see how it works out when people start using it.
(in fairness the modules are now consistent…so they do reinforce the terminology)

26

Yeah, x (left/right),y (away/towards me),z (up/down) seems to be established in many MPE apps by now. In CAD x and y are also often in the horizontal plane (as if you would have a paper/drawing table with a 2d graph/sketch on a table in front of you) with z going “outside of the paper”.

Perhaps it would be most natural to have the x axis along the chromatic/diatonic changes? So there could be a toggle between what we previously called “horizontal” or “vertical” layouts, where the chromatics are along the 24 keys or along the 5 keys - and that direction would then be “x”(?) (turning the layout would also help because one usualy wants pitch bends (“x”) in the same direction as the chromatic sequence - one is less turning the Eigenharp by 90° but more the semantics and thinking)

Would be happy to assist with alpha/beta testing!
Is there an easy way to revert VCV to the factory modules without creating a new account? Don’t really remember which those were. Well, probably the non commercial ones with VCV in the name…

2 Likes
27

I can do:

Alpha and Pico (Double and even Triple Pico “scenarios” ok as well Alpha+Pico.

I’m sure this will develop with testing, more testing :wink:

1 Like
28

I’ll gladly help with testing (all three models, Intel Mac), demo patches and documentation. And perhaps some modules down the line, who knows (sounds fun!). You’d want to keep me far, far away from graphic design, though, trust me. :slight_smile:

Not much help re the naming. For what it is worth, I never seem to remember what is what of roll and yaw. With X, Y and Z my initial assumption would have been X to be horizontal/timbre, Y to be vertical/pitch and Z to be pressure.

Have you given any thought on how to identify the buttons and percussion keys? I generally like columns and rows, but it gets a bit weird for those, perhaps?

2 Likes
29

yeah,I only got a grasp on yaw, when I started flying model RC planes :slight_smile:

what do others think?

X= timbre/yaw/cc74
Y= pitch/roll

it might take a bit of getting used to but for those with OCD tendencies might be more comfortable :laughing:

really, I don’t mind either way… its a pretty minor change.
so speak now, and forever hold your peace !

as a related topic.
currently I have the pitchbend input labelled as X - this would become Y!
this kind of reinforces, the labelling, however it might be better to just call it PBend and avoid axis all together … as in practice you can send it whatever input you want to it.

yes, these are broken out in the main Eigenharp module (unlike in EigenD).
Ive never seen a reason for them to be considered as a part of the main playing surface… the first thing you do is split them out !

also, whilst percussion keygroup has x/y/z … the mode keygroup only have key and gate (as hardware does not support x/y/z)

I don’t think so, demo patches need to be uncomplicated and focused on ‘teaching’.
the more complicated demo patches will later become similar to the factory patches we have in EigenD.
whereas for testing, you can use whatever floats your boat… and you enjoy.

the main thing here is some decent demo patches will help alleviate alot of support questions.

we may want to group contributed patches into two demo/tutorial and preset…

my main hope is, we will share on the forum, and gradually build them up, so many people might contribute to the same patch.

also the discussion around the creation, I think will help determine issues, and also shape what we think is needed.
(Ive noticed creating patches really does help you know what would be useful!)

yeah, just use modules with brand = VCV and your pretty much good to go (assuming no Pro sub, or bought vcv modules drums etc)
my main mistake when I did this with Antonio, was I forgot things like VCV Reverb were part of Pro, not Free.

reverting is awkward, you have to unsubscribe within the website, and then delete the modules folder.

there an alternative is…
if you run VCV Rack from the command like you can use -d to put in development mode, which basically uses current directory for plugins (rather than documents/rack),
(works on windows, but not sure of specifics)

but honestly, don’t worry about it too much… if you just use VCV brand modules, then when you hand preset over to me, I can run in dev mode to ‘test’ its not an unavailable module, theres only couple that might catch us out.
If I find something untoward then I’ll let you know for future reference.

tl;dr; don’t worry too much, just use VCV brand, and I’ll advise if any issue.

again… we’ll create a topic here, to discuss/share, so we will be fine.

2 Likes
30

progress… ok, I sorted out consistency yesterday.
just need green light on this x/y/z naming :laughing:

then I need to decide if I release EA now … or I might do a couple of changes first.

the main one, is possibly creating an ‘expander’ for the Splitter module.
currently Splitter splits a keygroup into two…
theoretically, thats fine… you can therefore split into an arbitrary number of splits by using more splitter modules… but sometimes it ends up with a lot of splits.
as you’ll want to split not only for playing surface… but also to bring out ‘function keys’ into their own group.
but Im a bit undecided… it may be better to get modules out there, so you can experience this… to better understand what Im talking about :laughing:

the other one, which is simple is allowing Function module to work as gate , trig and (possibly toggle). whilst in vcv you can already do this with other modules, it increases patch complexity.
I think this, probably, has priority.

1 Like
31

For me it would have been
X = pitch bend/roll or leftright as in pitch-yaw-roll-leftright-updown-forwardback
Y = timbre/CC74/pitch or forwardback as in pitch-yaw-roll-leftright-updown-forwardback
Z = timbre2/poly-aftertouch/updown as in pitch-yaw-roll-leftright-updown-forwardback
But I think I would be ok to adapt to whatever you settle on :wink:

Perhaps I will just install VCV free in parallel and use a fresh account for that.

1 Like
32

I’m pretty sure VCV Free will use the same modules as VCV Pro, as its same user rack directory.

if your using apple silicon… x86_64 and arm64 will use different modules.
though, again, it’ll use your rack subscriptions and download according to that.
… so really if you want to be sure, you’d have to run from command line with -d.

ok let me be clear… you can assigned what X/Y to whatever the hell you like :wink:
(this actually makes me feel, I should only use x/y/z when it truly is axis related…so scaler will have a PB input, not X as it currently does)

we are merely talking about if X = roll or yaw.
usually you’d think Y = yaw… as thats what eigend and mpe think, but that not consistent with columns horizontal axis.

honestly, if there is no consensus…im just going to leave as-is… as basically it seems, everyone is in the same quandry as I was when I implemented it :wink:

1 Like
33

Nudge, wobble and squeeze?
It’s also not right, but I realise I’m reaching for physical words in the physical space rather than trying to be abstract in a layer that’s not the abstract one.

In any case—don’t let is slow you down. Even numbered cc’s worked well enough to be useful.

1 Like
34

All good :slight_smile: I guess people can adapt as long as it is consistently used.

1 Like
35

nah, Im not introducing new terms… that’ll lead to more confusion,
at the end of the day, people will get used to x/y/z…
and as I mentioned, although current labelling is mathematically a bit odd/inconsistent… it is what most of us would kind of expect. (this is kind of why its difficult to change, and we aren’t getting consensus)

I think, I’ll leave as is … and review if it later becomes problematic.

2 Likes
36

The settings for VCV Pro and Free seem to be coupled, working with two accounts isn’t very practical.

But I found another viable way to mark the VCV built-in modules that are also availabe in VCV Free:

  • rename the user Rack2 folder
  • start VCV free (without logging in)
  • go to the modules list and add all pre-installed modules as favourites
  • log in to the account again and redownload the other modules
  • copy back custom presets etc. from the old Rack2 folder

Now the (currently 49) built-in modules have a yellow frame around them, are grouped at the end of the modules list and can be selected exclusively by enabling the “favorites” toggle at the top.
Only disadvantage is that one cannot use favorites for favorites anymore - perhaps a good opportunity to uninstall a few modules one doesn’t use anyways :wink:

37

sure, there are ways…
but, lets keep it simple, I don’t want people to think they need to start doing special install/setup etc, it’s largely unnecessary… just use the VCV brand module (and avoid Reverb), and 99% you’ll be ok.

once we start sharing demo patches, as a group we will review them… so any module that is problematic will be picked up during that process (and I’ll keep a list of no-go modules if necessary in topic)

a reminder of my goals:

a) its simple for anyone to do, lets not over complicate/make technical
b) we learn as a group how to make good patches for the Eigenharp
(likely develop some 'good practices) ( * )
c) develop patches that new users can learn from
d) patches that demonstrate functionality similar to that found in eigend.(supports (c) )

mid term, we may develop patches that offer similar functionality to ‘factory’ setups,
but this will come much later, once modules have stabilised and we have developed some ‘good practices’ (see (b) !)

initially, I want to avoid (at first) developing patches which do too much in one patch, as things may change, but also, they will be daunting for others to try to understand.
e.g. it might be better for us (initially) to have one tutorial patch that shows splits, and another one that shows how you can use Function to implement octave changes.

obviously, this could result in a lot of patches, so will need to focus/name and document them well.
which is in some ways I view them as ‘tutorial patches’ more than demo patches. ( ** )

the other implicit thing here is to focus on Meta Morph functionality rather than the sound design side… this is the main difference between demo vs tutorial?!

( * ) these days, vcv allows you to copy and save ‘groups of modules’ (aka selections) , thus allowing us to ‘reuse’ functionality across patches.

( ** ) this also helps for testing purposes, as its easier for me to understand if it goes wrong :slight_smile:

4 Likes
38

Wow, amazing work! Excited to try this out.
I’ve got an Intel Macbook and an Alpha that I don’t use often due to EigenD so I applaud your continued efforts to keep our Eigenharps useful and future proofed.

2 Likes
39

a quick update… this is still ‘ongoing’…
(or rather, I took a bit of time off, but restarted a few of days ago )

I decided before the early access to add a couple more modules that’ll make things a bit easier,
basically variations on modules that common use-case assumption, and by doing so can simplify the UI. (think of as , simple/advanced modules)

Split 4 -based on Splitter, allowing 4 splits vs 2
Switch 4 -based on Switch allowing 4 splits vs 2
Function 12 - based on Function allowing 12 functions vs 4

Function modules also now have 3 modes, gate, momentary and toggle, which makes it much easier to use.

however, whilst creating the new variants I decided I need to re-factor the code (particularly Split/Switch) basically to cover the N layers without duplication, and also fixing some minor issues (led redraws)

what’s left to do?

  • finish refactor work
    a day or so left on this, basically need to retro fit this back from Split 4-> Split etc.

  • update EigenApi
    I’ve talked about this before, thinking of changing the api a little… and it does make sense to do this before I release Meta Morph, so that Meta Morph can be a testing ground for these changes.

  • Scaler - currently this is chromatic, perhaps add custom scales.
    Im thinking of using something like the scales file from EigenD… or may just add common scales.

tl;dr; its more work than I planned to do before Early Access, but I think its worth the effort now… even though its delayed my plans.

that said, I have another project I really want to get back into… so I do want to get this out the door ‘soon’.

3 Likes
40

Feedback time…

Scaler - what’s needed?

basic function of scaler is to convert KEY → v/oct, this also involves deciding on row/column layout.
which its very flexible on.

its ‘limitations’ currently are:

  • chromatic scale only
  • lights root note

the reasoning is simple,
I think most use chromatic scales
I don’t want a lot of configuration within VCV… it’s not good at large UIs as they take up a lot of space.
once we go to v/oct (which is our musical ‘note’ interpretation, and may involve duplicates, I dont really want to have reverse mapping v/oct → KEY, so that limits where leds lighting can be done.

remember even though the output is chromatic v/oct - vcv has many modules allowing conversion to other scales (quantisers etc) … the main limitation here is led lighting.

ok, so my plans so far…

Other scales
Im considering selecting scales from a scale file which you can then select from in VCV.
advantage of this approach - keeps vcv ui very simple… just select scale, it potentially covers microtonal use.

Led lighting.
I’d like this in Scaler for the simple use-case, I think this is like EigenD… which is limited to ‘root’ lighting… this is what I already have in Scaler
(I think it kind of optional, since you don’t have to connect LIGHT output)

I thought about allowing (e.g.) 2 other scale degrees, but then you need to also specify colour, and its gets a bit ‘specific’… but I might do this, as its pretty simple.
how many is limited by UI… as currently the panel is ‘static’
e.g 3 (default to root, 3rd, 5th) is 6 params … 3 x degree + colour (off, red, orange, green)
I may do this… as I think this can fit in current module size.

another option I’m considering is an LED module.
this would NOT be related to scales at all.
my current idea would for it to be just read a file (a bit like the scales implementation), which would say which leds to light and their colour.

I’ve not decided on file format, but basically it would
a) contain multiple lighting schemes - so ONE file.
b) be easy to edit in a human form, cut n’ paste is your friend.

something like :

"Scheme 1" : {
    "red" : {
      {1,2},
      {1,4}
    },
   "orange" : {
      {5,1}
   }
},
"Scheme 2" : {
etc
}

ok, I don’t like the grammar (with curly braces) but if its json its easy to parse…

why is the above easy to edit?
because you will see we use row/column numbers… so you don’t need to think about key numbers.

this would handle the ‘static use case’ for custom lighting.

I might also need to optionally allow for a key press colour
so we might have something like
default colour : off
key press colour : orange (or off)

key press is interesting, since alpha / tau cannot really use this (nor need to), since in hardware they turn it orange… but iirc, the pico does not, so you kind of need to have this for user feedback.

anyway…

what do you think of the above?

what is needed for the early access release?
what shall I leave til latter once we all get to play with hit?

back to coding…

2 Likes