Forum

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:
https://plus.google.com/110586757591577940744/posts/betoZn81MeD


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.

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.

jim

Eureka!

http://youtu.be/zR_uEQev30Y
https://soundcloud.com/palaires/eigenharp-pico-cello-osc

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.

@TheTechnobear
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)

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 :-)

The core mapping functionality lives in piw/src/piw_keygroup.cpp and it closely ties together with the Python code in plg_simple/keygroup_plg.py (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,

Geert

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.

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!)