Question for y'allz about pad bank behavior

Share your wishes for the future of QuNeo
fingerdrummer
Posts: 12
Joined: Fri Nov 30, 2012 12:39 am
Location: berlin

Re: Question for ya'llz about pad bank behavior

Postby fingerdrummer » Sat Dec 01, 2012 12:47 am

B for me, too

as long as it does not rejekt other things (TOGGLE!) cause of too much code :)
djzach
Posts: 8
Joined: Fri Dec 28, 2012 9:51 pm

Re: Question for ya'llz about pad bank behavior

Postby djzach » Sun Dec 30, 2012 12:18 am

if it's not obvious by now...









B.

:D
demcanulty
Posts: 97
Joined: Thu Jun 16, 2011 11:24 am

Re: Question for ya'llz about pad bank behavior

Postby demcanulty » Thu Jan 10, 2013 12:34 am

Reading this now for the first time, we talked about it a lot in-office and finally I implemented A and C since those are the two behaviors available in all currently available devices, and the two that I had solutions for. But it seems like, at least in this sample of users, B is clearly the winner. The difficulty with B is that, in addition to keeping track of key state (something embedded environments are very good at doing), you also have to keep track of a large possibility of histories for that key and do different things depending on what that history is (something that embedded environments are very bad at doing because of memory constraints). It would be easy on a computer and max/msp does this kind of thing pretty well, because you can just throw heaps of memory and processor cycles at the problem and never miss them. But reading this makes me think that a lot of other people would also like to see something where you can hang presses across banks, and maybe if I think about it long enough a solution will present itself. I'll put this problem back into the boiler.
User avatar
jscott
Posts: 42
Joined: Thu Nov 08, 2012 2:52 pm

how to ensure note offs match note ons

Postby jscott » Tue Jan 15, 2013 2:26 am

Hey Dan, good to hear it. I meant to post here before on this but didn't get around to it. I've solved this problem myself multiple times so perhaps my thoughts will help.

The key is of course you have to send the note off on the same note as the note on, regardless of what the current note-on assignment is for the pad.

With an instrument with a large number of keys, this is more complicated to do in a small RAM space since you have to build a voice allocator. But since the Quneo has a limited number of sensors, there's a simpler approach. Here we are really talking about the 16 pads, which can be up to 64 pads if all are quadrimated/put into grid mode. So what you do is you have a buffer with 64 entries and when you play a note on on any pad, you store the note-number-on and its channel in its corresponding slot. When you have the note off event for the pad, then rather than use the current note on, you look up what note and channel were sent for the previous note-on and send that. Very simple. A nice part about it too is that regardless of what note switching or transpose effects happen, this algorithm doesn't change. And it only uses 64 bytes of RAM to store the whole state for the notes and 8 bytes for the channels (since quadrimated pads share their channel and channels are 4 bits each). Only 72 bytes altogether. That doesn't have to be persistent memory, or per preset - it's just scratch memory.

On a related topic while I'm discussing note on and off, it would be really nice to have release velocity with those note offs, just track the velocity as one leaves the pad and map to release velocity in the note off event. Not many controllers do this, several Alesis instruments do, it allows doing things like modulating the release envelope according to the speed of release, which is useful for controlling note articulation.
jeremy tranter
Posts: 4
Joined: Sun Jun 02, 2013 2:15 pm

Re: Question for y'allz about pad bank behavior

Postby jeremy tranter » Sun Jun 02, 2013 2:27 pm

I'm using QuNeo to control Mobius live looping software. Mobius has various "Sus" functions.... i.e. a function is turned on while the note is pressed and turns off when released.

Present behaviour is QuNeo sends a note off for each pad when you change bank (16 in drum mode, 64 in grid).This toggles all the "Sus" functions when you change bank.

I'd like an option of an additional checkbox to not send these Note-offs when assigning buttons for bank switching i.e. a choice between your options a and c.

Regards

Jeremy

(have also raised this as a support ticket, posting on forum in case of interest to others. )
dijidave
Posts: 35
Joined: Fri Sep 14, 2012 4:16 pm
Location: Upper Crystal creek, NE-NSW, Australia

Re: Question for y'allz about pad bank behavior

Postby dijidave » Sun Jun 02, 2013 6:59 pm

jeremy tranter wrote:I'm using QuNeo to control Mobius live looping software. Mobius has various "Sus" functions.... i.e. a function is turned on while the note is pressed and turns off when released.

Present behaviour is QuNeo sends a note off for each pad when you change bank (16 in drum mode, 64 in grid).This toggles all the "Sus" functions when you change bank.

I'd like an option of an additional checkbox to not send these Note-offs when assigning buttons for bank switching i.e. a choice between your options a and c.

Regards

Jeremy

(have also raised this as a support ticket, posting on forum in case of interest to others. )



I 2nd this request, as I want to play with "Arps" over different banks :ugeek:
Regards,
Dave
jeremy tranter
Posts: 4
Joined: Sun Jun 02, 2013 2:15 pm

Re: Question for y'allz about pad bank behavior

Postby jeremy tranter » Sun Jun 09, 2013 12:06 pm

Following a short discussion via a support ticket I've posted a concise feature request on the Wish List thread.

Regards

Jeremy

Return to “QuNeo Feature Wishlist”

Who is online

Users browsing this forum: No registered users and 1 guest

cron