EigenD 3.0 - Beta-2

Eigenharp
61

yeah, its an area thats not 100% clear from a UX point of view.

it comes from the migration days of ‘single window’ apps to multi doc.
there was an idea that single window apps close still - but you have to have the concept of a main window… close that , closes app.
whereas close a doc, apps stays up

so yeah, different apps behave differently.

yeah, if you want to minimise it to get it off your desktop…
but thats what the minimise button does :wink:

ok, rewrote most of midi input and output agent, well at least around device select… was. bit of a mess.

One thing Ive also changed… but is up for debate :slight_smile:

Ive changed to using
“EigenD In 1” and “EigenD Out 1”

why?

see there is an oddity… that you can actually connected a
midi input agent, to a midi output agent via midi virtual devices.

so for me this gets rather confusing, if both are called “EigenLabs 1”

for me, seems less confusing to have explicitly names ports for IO.
thoughts?

EDIT: ah, just realised it was more than an oddity…it’s confusing !
so if you had a midi input agent and a midi output agent, they’d both create a virtual device called “EigenLabs 1”

IF you selected “EigenLabs 1” , you were actually selecting the Midi Output output (EigenLabs 1) .
This was why there was no control over the virtual device ant id was always active.
because the one you saw in the drop down was for the ‘opposing’ input/output agent !
something you are very unlikely to want.

now its much clearer
in the mind input agent you will see something like:
None
EigenD In 1 ← the virtual input for this agent
IAC Driver Bus 1
Virus TI 1
EigenD Out 1 ← from midi output (you could have multiple of these)

so you can still connect to the output agents virtual device if you really want.

(you can see also why they have to be named different too… Otherwise Eigenlabs 1 would appear twice)

I can see there still be some confusion over whats presented, esp once you have multiple midi input/output agents. but thats kind of the nature of virtual devices… once create they become ‘real devices’

1 Like
62

Added a log and a video to the mode key issue. How do you plug the Alpha to the Macbook? Directly via USB-B to USB-C cable? (I currently have USB-B to USB-A on a passive 4xUSB-A to USB-C hub). If everybody but me is using a hub-less connection and cannot reproduce this then it might be worth to buy such a cable, too. (USB-C/TB ports are not really plenty on the MacBooks but I would still have one free).

63

I use a usb 2 hub (powered) , always used it…
that said, unless your getting a lot or warning about lost packets, I doubt thats the issue, as it’d not be particular to menu functions. (that why I suggested looking at thresholds)

I dont get why in your video your repeatedly pressing and releasing the key?
to use the menu you have to hold it down…

sure, if you press and release repeatedly then try - perhaps its getting confused - or it could be its queuing alot of of led messages, and so overrunning a buffer.
but Im not that motivate chasing an odd edge case - its not really a normal use case.

64

Pressing fast several times in a row seems the fastest way to get it to work. When I press long then nothing seems to happen at all.
But I will likely switch to a native mode-key less setup soon again anyways and it is workable. So, not high prio.

Edit: Ok, your threshold comment was on spot: When I hit the key really hard (or: harder than I currently tried) then it instantly works. So I will have to play with the threshold (or make it a habit of pressing harder…). Sorry, haven’t used mode key based setups for too long anymore it seems :smiling_face:

Edit2: The trigger is not pressure but velocity based (so increasing pressure doesn’t help one has to release the key and press it harder from the start)

65

Just tested: The processing code seems to continue to run when closing the EigenD main window. Ok, so there might be some people who prefer to close the main window so it doesn’t come up when cycling through open windows. (Not me though, would be fine with EigenD closing when the main window closes.)

66

Ive never messed with thresholds.
I just know they are something to do with menus (and likely the belcanto entry hence the hard and soft ).
pretty sure they aren’t used musical, as that side all have the velocity calls using raw pressure data.

perhaps as you say, if its velocity based then you need a certain attack to hit the threshold… otherwise its not registering.

Im not sure how much variation there is between alphas vs user preference.
e.g. too light and you’d get false positives. too heavy you have to thump the key.

the fact there are two settings there, means it was like a user requested some control over it.

Id suspect this is all intentional, so that if you just brush the mode key whilst you are performing you don’t suddenly end up interrupting your performance data stream.

funny, Ive never had an issue with it…

I doubt it’s changed, so Im surprised you are only noticing it now ?!

67

From memory I would say it reacted to a lighter touch before, like for Pico now. (On Alpha as it is now I have to press the key several magnitudes harder than on Pico to get a reaction). But as said, I haven’t used mode key based setups on Alpha for a long time (only all one playing surface), so I cannot say when (and honestly not even for certain whether) this changed.
But it’s fine as is, I can get used to it.

Edit: When changing “hard threshold” on alpha keyboard 1 from 0.19 to 0.1 then it works intuitively for me again - so I can just do that! (Edit: 0 is even better!)

68

pico/tau mostly have menu keys on click buttons, totally different - they dont have thresholds purely on/off switches. so they don’t need this ‘protection’ from brushing.

as you say, its not really about light/heavy its about being positive, Im sure if you gently touch it, it wont activate - by design.
like most things, if you use it regularly, you likely get a feel for whats need, and so don’t notice it… its just how it works.

as for what hard/soft is,
just checked the code. it is max pressure within an estimation windows, looks like 10 samples. so a primitive velocity I guess… this just affects key hard/soft signals.
so yeah, if you touch it slowly it will not activate. also if you dont release the key properly it likely wouldn’t retrigger (as its the first 10 samples on key activation)

this code is all c++ and so not changed, for a very long time (if ever ;))

69

Just checked, the default threshold value (800/4096) hasn’t changed since EigenD 1.4 :slight_smile:

70 
#define THRESHOLD_GATE 100
#define THRESHOLD_HARD 800

pressure at this level is still done in integers, so its actually using 100 (soft) , 800 (hard).

the floats are used in signals/display, hence 800 / 4096 or 100 / 4096.

not really sure which is used for key groups without checking key group code, Id guess hard?.

but yeah, as I said this area has not changed… and its not an area that would be affected by things like juce/python/c++ changes.
so unlikely this has changed in a very long time… if ever.

its seems a perfectly reasonable design choice to stop you brushing keys whilst playing and interrupting your performance… you don’t really ‘need’ to switch to the menu quickly, that not really what the menus are for. you have talkers for this kind of thing.

anyway… doesn’t seem like a bug to me??

71

Yes, hard is used, the behavior immediately changes when adapting the hard threshold. Not a bug, makes sense, yes, have closed the issue. Should have known/remembered that…

72

yeah, has to be KEY_HARD as thats what the pico/tau send for their click buttons, and the code beyond the device layer doesn’t differentiate after that.

73

funny, I had to dig this up, as a reminder to myself about, why would EigenD allow? or act like this?

its worth another watch, as you can see why at time EigenD feels a bit ‘fragile’ / odd.

1 Like
74

@Kai
you can find loops / impulses on this topic I uploaded a while ago.

factory resource like these usually live in /usr/local/pi
they can also go in ~/Library/Eigenlabs

I cannot remember if setups care, e.g. do the factory refer to /usr/local/pi… or just the filename and search both?!
(I always put factory ones in /usr/local/pi - so haven’t test this)

1 Like
75

k, so I went back to main rig, to see if I could have better luck that last time I tried… or see if I could isolate any issues.

the main issue was the Osmose was ‘actiing’ up and getting laggy.
but as reported on this topic it seems like its just the Osmose…
plug in the Eagan Matrix Module, and it behaves perfectly !

has anyone else noticed this with the Eigenharp / Osmose?
can you see the same thing?
(osmose firmware : 21.21 /10.52)

when I first got the Osmose, I know I tried with the Alpha, and I don’t remember this issue. Im sure Id have strummed all the keys, it’s kind of the thing everyone does with Eigenharps :laughing: … and its very noticeable, even with decimate turned up fully

is this a new issue with later Osmose firmware perhaps ?

ofc , remember, is a key word here…
it’s quite possible, it was new, and I ‘forgave’ such oddities, giving it was new firmware - and could improve over time.
anyone with a better memory :wink:

notes:

  • its exactly the same with 2.2.1… which I would have used when I first got osmose - so its not a 3.0.0 issue at all.
  • as per other topic, exact same setup , works fine on EMM
76

ok, things just got superweird !

so I was looking at the above, and couldn’t understand why decimation wasn’t curing the problem with Alpha … as 100ms is only 10msgs/sec !

looking at the midi monitor, indeed I could see decimation was having no effect !
(still an issue that Osmose could not handling full rate - but ‘understandable’)

OK, have I screwed up ? hope 2.2.1 behaves the same - decimation looks totally broken.

hmm, come back to my dev mac, try with the pico and tau.
decimation is working perfectly,

try with my laptop with same build as on my main rig.
decimation is working perfectly,

OK, its an alpha issue, or something to do with the setup
take my Pico into main rig, plug it in directly.
decimation does NOT work.

its just that one Mac mini,
identical Mac mini m1 works fine with pico, with exactly the same build/setup and pico/ usb cable. (as does the laptop!)

is decimation working for you?
it easy to spot just use midi monitor, just look at (e.g.) channel pressure , press and hold one note.
if you set decimation to 100, you’ll get something like 5-10 messages.
at zero/not working, you’ll get a lot :wink:

at the moment, Im completely stumped…
it kind of explains why the poor old Osmose was struggling.
but Ive zero idea why one Mac is behaving completely different to the other.

the code for decimation is very simple… really I can’t see how it’d fail .

guess… I need a special debug build, which is kind of annoying !

FIXED !

old Eigenlabs code - incorrect type coercion, leading to inaccuracies, depending on current time values. really weird one.
still a bit unclear why it reliably failed on one machine, and worked on 2 others.

definitely helps, the Osmose… I think 50ms, but hard to say exactly,
as Osmose can still overflow if you send enough notes fast enough, as you (obviously) don’t decimate notes

to get the right decimation value, you’d want to flood it with c74/ch p whilst not changing notes - thats a bit difficult, as you likely wont be able to hear its lagging.

1 Like
77

Great you found it!
For once a problem that doesn’t seems to appear on my system: Opened “midi rig 1” and then “midi converter 1”, changed “minimum decimation” to 100, now I get substantially less midi events than with default setting 0. (Edit: The setting is also available under “Settings” in the Window->Midi Converter 1 UI. Changing it there also works for me.)

1 Like
78

I also get a noticeable “event queueing” with minimum decimation 0 for Osmose (played over USB-midi). Setting decimation to 20 or higher solves this.

1 Like
79

Decimation is working here - Pico and Alpha - standard setups and MIDI Basic

1 Like
80

yeah was a weird one…
its funny, its one where I looked at the code and thought “hmm, thats not the way I do it - but looks ok” - but then after some debug logs, I knew exactly what to change …
as a developer, always wise to trust your gut/instinct :wink:

1 Like