Forum rss-feed


Software: Musical mapping being ignored in factory pico setup - bug?

Most Recent

written by: TheTechnobear

just an update, I suspect the original issue also was 'affected' by the fact that channel ids were not allocated on rig input.
as keyman said in another thread, this is required for rig inputs.

(sorry, keyman your comment in this thread talked about 'filter' on the connection, hence i didnt think about channel ids... but perhaps i should have!)

written by: TheTechnobear

Wed, 20 Feb 2013 17:27:34 +0000 GMT

I think ive discovered a bug, where the pico factory setup contains hidden links to the keyboard mapping, or at the least some 'inconsistent' behaviour which id love to understand :)

background is at:

test which shows issue (i think) is in my last post, which i'll repeat here:

ok, i can prove its a bug (in the pico setup) in 3 easy steps :)

1) open up the standard pico setup in workbench

2) edit main keyboard group - edit musical mapping, clear it, then add just one entry 1-1 -> 1-1, ok

Test: press keys 1/1 and 1/2 you will note all keys produce a sound, they should not - only 1/1 should.

lets prove it :)
3) open sample 3 (piano), create audio unit, and set plugin to any plugin. now connect cycler to new audio unit, and audio unit to gain.

Test: press keys 1/1 and 1/2, again piano will play on 1/1 & 1/2 (and all others) (incorrectly) BUT the new audio unit will only play on 1/1 (correctly)

Ive messed about hacking the pico factory setup, and if you mess with it enough (ie deleting components and recreating), it suddenly starts working properly. my suspicion is the setup has some weird hardwired connection, but its hard to see what.

Wonder if +Geert Bevin has seen this, or its a known issue?

EDITED: more info...
Okay, the problems appears to be some oddity in 'hidden connections' i think, and it affects different rigs in different ways.

The above test, showed that the sample oscillator has an incorrect hidden connection. (hence why the AU works, i suspect a new sample oscillator will fix it)

In AU1, ive did the same, and the new AU had the issue, but then i deleted the Scaler, and wired in a new one, and its now works
i.e. in the AU1 case, its the scaler which has the incorrect hidden connection.

I'll crosspost this to the eigenlabs forums see if we can get an official response.

written by: TheTechnobear

Wed, 20 Feb 2013 18:51:02 +0000 GMT

okay. done a bit more digging...
actually, its NOT the setup....

it appears to be that a difference between sample oscillators & audio units
to be more precise, its sample oscillator + ahdsr vs audio unit...

basically audio unit, only looks at the musical mapping
whereas the sample oscillator (+ ahdsr) is also some how using the physical mapping

this is rather hidden, since you get different results for each, despite the fact they both take only pressure input & frequency,
so attaching to the same source you get different results!

written by: jim

Fri, 22 Feb 2013 16:47:22 +0000 GMT

Keys are expected to have both a musical and physical mapping. It's a bug thats crept in that you can have one without the other.

When you don't have a musical mapping, what happens is a bit random.

If you want to cut off the keys, take them out of the physical mapping as well.


written by: TheTechnobear

Fri, 22 Feb 2013 18:13:21 +0000 GMT

but if you don't have them in the physical mapping , they cannot appear in the key group outputs

ie you cannot use them as pure control keys - which what I was trying to do

Test : try adding 1/9 as a control key to the main keygroup in pico setup

Also I'd be interested to know why it's works one way with AU and another with others eg sample oscillators

to be clear, im trying to build up an understanding of how this all works, so I can contribute to community... yes, i can work around,
but this doesnt help me answer the "whys" , as you will see from the G+ thread, I put alot of time into this to try to get a deeper understanding of what was going on.
(im a typical programmer, i hate it went i dont understand why something is behaving, in my mind, inconsistently !)

written by: keyman

Sat, 23 Feb 2013 03:22:05 +0000 GMT


Back then (Sep 2012) i called it "a nice bug" and now we have this understanding from @Jim about "keys are expected to have both a musical and physical mapping.

What I did was JUST added a physical key (2.9) and on top this connection:
keyboard pico 1 pressure output to cello rig 1 bow velocity (create a new output in the gateway) filter 18 (so key 18 is the "trigger base note")

Result? - nice musical randomness (with just one key being pressed)
I should say,this could be more investigated in a good constructive way.

To use keys as you mention Pure control keys, think you have to "filter" the keys you like (edit tool over a wire to get Connection details)

written by: geert

Sat, 23 Feb 2013 08:42:16 +0000 GMT

I don't really have time to test this for the moment so I can't comment on this particular behaviour.

Jim, I know we decided on both being mandatory in the initial design. However, afterwards I remember that I had to change this and make them totally independent. Agents could use musical, physical or both as it suited to their implementation. I can't remember why exactly we changed it, but it was a good reason, driven by initial user feedback with the EigenD 2 new key streams.

written by: geert

Sat, 23 Feb 2013 09:07:40 +0000 GMT

Ok, so I did have a quick look at it :-)

After very rapid inspection I think this is related to the whole sampler/scaler/ahdsr setup. The ahdsr triggers the sampler envelope based on the pressure input, which is not related to key position information at all, it actually has no key input to look at. So any key that's sending pressure data will day, even if it only had physical coordinates for the key positioning. This then triggers the activation input on the cycler, which makes the sampler oscillator start a sound and it looks for a matching frequency it should play. I think that here might be something that goes wrong with what the scaler does. The scaler seems to send out an event for that particular key that has a frequency data stream with no information, as in it's empty since there's no musical note position, but the event is there. So the sampler oscillator gets the activation trigger, gets an empty frequency stream that has the same identifier ... and then something random happens since I guess the implementation of the sampler agent doesn't know what do do with this.

Long story short, I think it is a probably just a simple bug somewhere and we shouldn't draw any big conclusions from it. Physical key positions are totally independent from musical key positions in design, physical is for things that are tied to the physicality of the instrument (talkers, keygroup outputs, ...) and musical positions for things that are related to music and sound :-)

written by: TheTechnobear

Sat, 23 Feb 2013 14:44:43 +0000 GMT

thanks guys, i really appreciate you taking the time to look at it, and also explain.

Im pleased to hear physical and musical are supposed to be independent by design... as otherwise there is little to no point in having both.

geert, where is this 'filtering' done? i looked at the source code, but found it a bit tricky to follow, i could see in the keygroup where the mapping and reverse mappings were help, and could see the filter function, but not where it was applied...
(if you can give me a couple of classnames im sure i can work it out from there.

Also, i think there are issues with 'subfiltering' i.e. if you specify a physical map on one keygroup, and then take another keygroup off of that. i kind of mentioned it in the g+ thread. but didnt isolate it clearly enough to 'report it'.
(basically i found, i had to have an empty physical map in the parent for it to work)

another thing, im interested in from a 'design' aspect...
Ive notice that on a keygroup, the outputs key mappings are dont after the 'physical mapping' in that key group. but the mode key is done 'pre mapping'
the later is more useful, due to the above bug/limitation/issue :)

I think it would be better to have move 'pre physical map'

input keygroup (KG1) sends 1/1-8, 2/1-8
but we create a split keygroup (KG2) restricts 1/1-4, 2/1-4

now, i have a key outputs 1-16.... i cant actually map all now, because i only have 8 keys due to physical map (1/1-4,2/1-4).

you can see this going on in my pico split, originally i planned to do the instrument selection (from key 1/9, 2/9) as rows 1/1-8, as in factory setup, but i couldnt ... i had to use 1/1-4,2/1-4.
Actually i prefer this setup as it happens, but what if i wanted 16 rigs?

Also you'll note, as i said, the mode key doesnt have this limitation (thankfully), as i can use 1/9,2/9 even though they are not in KG2 maps.

Again, thanks for explaining this, and from my part im willing to dive into the source to work stuff out, if you give me a few pointers...
(ive watched dev videos, and dug through the source etc, but there are not many comments in the code, and alot of 'generic' types, which make it difficult to sometimes follow it through)

One last question, for john i guess... given recent announcements, what the general plan for 'next version' fixes etc?... or even open source commits?

Sorry, if pestering with so many questions... but keen to learn :)

written by: geert

Sat, 23 Feb 2013 16:34:22 +0000 GMT

The core mapping functionality lives in piw/src/piw_keygroup.cpp and it closely ties together with the Python code in plg_simple/ (mostly the *mapping* methods there).

The mode key is listening to upstream key data, basically you define which upstream key is used for switching modes on a keygroup. It usually is a key that lies outside the keygroup it's the modekey for, which is why it's not using the keygroup's mapping it's switching modes for. The outputs are specific for the keygroup they belong to and are by nature physical, so they obey the physical mapping.

I'm sorry, but I really don't have time to read through everything you write, try out your setups and wrap my brain around what you're trying to achieve. I hope these answers are useful still.

Take care,


written by: TheTechnobear

Sat, 23 Feb 2013 20:28:31 +0000 GMT

No problem, I'm happy for any input I can get :)

My point was, the keygroup outputs control keys could also be based on the upstream data (same as mode key) and pass on the filtered keys downstream.
This would still be consistent and would allow a bit more flexibility.

you lose nothing, as that KG agent is dependent on upstream
mapping anyway for mode key & phys mapping relationships

Anyway thanks again

written by: geert

Sun, 24 Feb 2013 09:22:02 +0000 GMT

That's not how we designed nor intended it, everything that is part of the keygroup, and output switching definitely is, should be effected by the mappings, that's the whole point. Counter example, apart from me finding your suggestion unintuitive, it would be impossible to change the physical layout of the first keygroup's outputs since there's no other upstream keygroup to remap them. You'd have to start inserting dummy keygroups just to remap, which is to me a sign of a wrong abstraction.

Also, even if there would be some merit to making a change like this, it would invalidate all existing setups.

written by: TheTechnobear

Sun, 24 Feb 2013 12:10:17 +0000 GMT

Well, of course there are different ways to view a problem, thats the fun in software design.

I'll explain why i dont think its unintuitive - but only for completeness, i understand and accept your/eigenlabs viewpoint as also valid.

As I see it, keygroup is a switching component which applies mapping/filters to its output. It is pretty normal for switching components to have access to all input data to make the switching decision. hence, filters etc are often placed after the switch logic.

you have hit the nail on the head with the dummy keygroup. If you applied this logic, then indeed if you wanted the existing logic you could implement with a dummy keygroup. i.e. its not impossible/difficult, just an extra step.
but with the existing logic, you are restricted, possibly you can replicate, by putting an additional keygroup on each output - in my case that would mean 16 extra keygroups.
(sometimes i think you cannot workaround, but its involved to say why, so i won't bore you :))

as for the first keygroup, this is not true, it always has the physical keyboard layout, and that is already implied by the physical mapping in the top keygroup in the existing logic.

of course, you are completely correct it would change existing setups... that i cannot deny :)

anyway, as i said, this is just to make my idea clear, your view is also clear/valid.

written by: TheTechnobear

Mon, 25 Feb 2013 17:49:48 +0000 GMT

just an update, I suspect the original issue also was 'affected' by the fact that channel ids were not allocated on rig input.
as keyman said in another thread, this is required for rig inputs.

(sorry, keyman your comment in this thread talked about 'filter' on the connection, hence i didnt think about channel ids... but perhaps i should have!)

Please log in to join the discussions