Threshold detection and pattern matching

[d.andrew STEWART]

Hello

Here is another programming challenge I am trying to realise in Max.

-Using five continuous controllers, each played by a single finger [controlled by the fingers of my hands – like playing piano keys]

-I convert the continuous values to either 1 (on) or 0 (off) based on threshold detection

-0.0 to 0.199999 is OFF and  0.2 to 1.0 is ON; rather ON is triggered when value passes threshold 0.2

This is the easy part

-Next, I take the on and off states (1 or 0) of all five continuous controllers and convert them to a new value

-I convert a bit – formed by the on and off states – into an integer (base 10)

Still easy

-Because the five controllers are continually sending out data, it's difficult to form the precise bit value without accidentally triggering an unwanted bit value

-This issue concerns the actual physical design of the control surface (karlax) and the physical challenge of playing the continuous controllers in such a controlled way

-Can any DOT object be used as a pattern matching system to help map the continuous data to the desired bit value?

Thoughts?

Thank you
DAndrew

[d.andrew STEWART]

By the way, this seems like prototypical case for pattern matching via machine learning – I want to teach the system to recognise the states of the five continuous controllers; but the system needs to be fast – very fast. And it needs to discriminate – to know when a continuous controller's value is no longer relevant, even if the value is still being modulated.

Anyone have an idea?

[d.andrew STEWART]

Hello mappers.  I'm back at it and enjoying DOTs and LIBMAPPERs.  I'm still struggling with a finger (depress keys) programming strategy. Does anyone have any thoughts on how to approach this in Max?

It's hard to explain in words what I am doing with the karlax (DMI) keys; in addition to detecting upper and lower thresholds, I have a pattern matching system: an additional layer that is continually receiving karlax key info (between 0.0 and 1.0) and when a match is made, the   threshold value is allowed to  pass (above 0.2 a sound is triggered; then less than 0.1 sound is silenced).

Perhaps what I'm describing is a dynamic "filter" system where the centre frequency is constantly changing (based on the continuous values of the keys). When the "centre frequency" matches a specific value (corresponding to a specific combination of depressed keys), again, the threshold value is permitted to  pass through, triggering, or silencing a sound.

I'm looking at dot.schmitt, but I still wonder if what  needed is more sophisticated pattern matching system

[d.andrew STEWART]

Ok, I have devloped a sollution for the keys (continous controllers) of the karalax. 

I'd now like to implement a similar strategy with the karlax pistons.  The pistons are only on/off (1/0). So, piston combination timing seems to be the vital component. This issue concerns the actual physical design of the control surface (karlax) and the physical challenge of playing on/off buttons in a synchronised way. I'm using [thresh], followed by [zl ecils 1]. This retrieves the last number if the list – the last number equalling the last piston combination sent.  Any other thoughts?

I think I need some way of accounting for an anticipated , delayed, press of a piston. The delay occurs naturally as a result of the shape of one's hand and finger action/expanse. Of course, we're also talking about training the body/hand to play "synchronised".