Am I barking up the wrong tree with this?

Seems like you are :) Connect your top [line] to print and see what it spits out. At 10ms I only get 0 and 128 so logically that would mess up your non-MSP approach. Sections are just skipped.

Probably something similar is happening in the MSP variant.

[Line] has a default grain time of 20ms. Set at 1ms grain I get 3 of the buttons to light up, still not all.

But then, what input do you want to analyze like this? 10ms is bloody fast...

Hi as DTR states, the control domain will not give you the responsiveness you require; a combination of [delta~] and [edge~] is quick enough, and gen~ would get you even further. Here's an MSP solution to the problem (without the % divisions that you require but that should be easy to do):

HTH

Brendan

Thanks for the help guys, as you say Brendan this clearly needs to be in the signal domain and your solution clearly identifies the 0-no zero transitions. The issue I am having now is that I need to know when the signal resides within a range and I need to know which range it has passed into.

To explain my rational a little more, I want to split CC data up to trigger MIDI note data. This is easy enough when you are using a pan pot (I just use the [scale] object) but I am using a variety of sensors that output slightly erratic data. This sometimes results in fluttering between notes, even if the performer is keeping quite still. I have tried adding "silent" patches between notes to compensate, but then you end up with notes that flutter between on and off. Smoothing the data is obviously an option but I don't want to loose too much control and you still end up with flutters at the lesser degrees of smoothing I would require. So enter this convoluted solution (see picture attached):

In this instance, imagine the CC data has been split into 2, so triggering 2 MIDI notes. Notes are triggered in the red areas [B] and [E]. To stop the flutters, and to allow the retriggering of the same note if required, once the user has triggered note [B] say, they would need to move into sections [C] and then [D] before moving back through [C] to retrigger [B]. Just moving into [C] won't allow you to retrigger [B], you need to progress through 2 sections. This stops flutters, but allows retriggers of the same note if desired.

This solution will work, I just need to execute it correctly! The reason for the very fast line times is that if you split up the CC data into 16 notes or more, and someone moves quickly from 0-127, you are dealing with very fast transitions and I want them to be able to trigger each and every note they pass through.

I have come up with this patch but there are several issues still, [bitxor~ 0 1] does what I want but it outputs bangs relatively slowly (as can be seen in the max window). [bitand~ 1 1] should do what I want but it seems to output bangs in the wrong order (again see the max window).

sorry for the very long reply!

There's likely to be timing issues again on the extreme fast end when going back from signal to message domain. Maybe you could consider the non-signal approach after all because if your input value goes from 0 to 127 in 1 time step you can derive that it has crossed all steps, even though you didn't actually receive the reading of all of them. So your logic could be to calculate not where the value is at a given instant but which zones it has crossed since the last reading. Compare new value to previous value.

This doesn't solve the case of the reading going up and back down within 1 time step (0-127-0) but how likely is that to happen? Chances are the midi interface doesn't even operate at that speed.

Hi Barry another possible solution might be to further stabilize the sensor data; what sensors are you using? I find the simple algorithm below eminently usable in my own work (DIY sensors, impaired capabilities, custom DMIs, naive electronics skills), and it's also quite flexible. Noise filtering does of course introduce a degree of latency, but I use this method regularly and my fellow musicians have yet to complain about noticeable lag. It's very responsive if you tweak it. I understand your frustration if not your attempts to solve it.

HTH

Brendan

. . . and you are of course familiar with the [onebang] object. In related logic scenarios it is also very useful! If only because I don't quite grasp bitwise logic ;)

I am using a variety of sensors that output slightly erratic data

Maybe this will help? http://en.wikipedia.org/wiki/Gray_code

New for 2014: discrete trigger zones and variable noise-reduction exponent! Hurry!*

*Not a flying toy, batteries not included, experience may differ from those depicted or otherwise implied.

Is it 2013 or 2014..I'm confused

Ha ha

I've been writing 2012 everywhere today; wtf??

Some really great stuff here, thank you both very much for the help! I'll have a play and report back in a couple of days. :)