I'm going to test the NRPN controller now, I'll let you know the results.
Tablet 2 MIDI - Bugs thread
-
- KVRAF
- Topic Starter
- 1511 posts since 2 Jul, 2004
-
- KVRer
- 12 posts since 6 Jun, 2004
I did some NRPN tests. The good news is that is it works, the bad news is that it doesn't work well. The NRPN controllers work very erratically. So I've compared the NRPN output of Tablet 2 Midi with the NRPN output of my Peavey StudioMix hardware controller in MidiOX.
The NRPN Tablet 2 Midi output shows a RPN MSB and a RPN LSB after each Data Entry MSB and LSB and before the NRPN MSB and LSB:
NRPN MSB
NRPN LSB
Data Entry MSB
Data Entry LSB
RPN MSB
RPN LSB
NRPN MSB
NRPN LSB
Data Entry MSB
Data Entry LSB
etc etc
The Peavey NRPN output does not show these RPN couples at all.
If necessary I can mail you the MidiOX screenshots with all the data for both Tablet 2 Midi and the Peavey.
The NRPN Tablet 2 Midi output shows a RPN MSB and a RPN LSB after each Data Entry MSB and LSB and before the NRPN MSB and LSB:
NRPN MSB
NRPN LSB
Data Entry MSB
Data Entry LSB
RPN MSB
RPN LSB
NRPN MSB
NRPN LSB
Data Entry MSB
Data Entry LSB
etc etc
The Peavey NRPN output does not show these RPN couples at all.
If necessary I can mail you the MidiOX screenshots with all the data for both Tablet 2 Midi and the Peavey.
-
- KVRAF
- Topic Starter
- 1511 posts since 2 Jul, 2004
thanks hansvr - The RPN reset messages were recommended by a guy called Philip Rees, who considered it "best practise" to reset the controller numbers after each message. Perhaps these resets are not interpreted in the intended way by your receiver.
Heres the URL: http://www.philrees.co.uk/nrpnq.htm
I'd be interested in a midiox screenshot of the peavey, thanks - no need for a screenshot of tablet2midi messages - I have midiox installed.
I will try removing the RPN messages in the next release hopefully it helps. If not then I could try reducing the data rate - might be a little on the fast side.
Heres the URL: http://www.philrees.co.uk/nrpnq.htm
I'd be interested in a midiox screenshot of the peavey, thanks - no need for a screenshot of tablet2midi messages - I have midiox installed.
I will try removing the RPN messages in the next release hopefully it helps. If not then I could try reducing the data rate - might be a little on the fast side.
http://www.livelab.dk - slice up your life
-
- KVRer
- 12 posts since 6 Jun, 2004
I see why Philip Rees regards this best practice for hardware. But these RPN 127, 127 messages are indeed not properly recognized by the ArtWonk software. Maybe it is also a problem for Cubase, I couldn't get Tablet 2 Midi NRPN to work at all yet (Peavey NRPN works OK).
When the next version appears I will try it and get back to you with the results.
I'll send a pm with the Peavey screenshot.
Thanks for looking into this!
When the next version appears I will try it and get back to you with the results.
I'll send a pm with the Peavey screenshot.
Thanks for looking into this!
-
- KVRer
- 6 posts since 21 Feb, 2006
hello,
i posted this yesterday. I created a new "topic" which was i guess wrong, as every bug report should go in this topic here. I thought topic is the 'subject' of the report...
first i want to thank you for developing this tool! I always wanted to have something like this. I hope i can contribute to improve it.
I have a Wacom sapphire cte-430. The midi loopback device is midi yoke.
Here are my test/bugs/improvement request.
The mentioned wav-files can be downloaded here: www.errorsmith.de/unlinked/tablet2miditest.zip
I made following tests concerning the timing of table2midi:
1. To test the delay between the actual physical hit of the pen on the tablet and the received midi event, i miked this hit with a microphone, routed it in reaktor via my soundcard and recorded it together with the received midi gate in reaktor as an audiofile. The same i did with my midikeyboard. The audiobuffer of my soundcard (RME Hammerfall) was set to 11 ms. What i meassured disapointed me much: While there is no delay between the micrphone click and the midi gate of my midi-keyboard. (Since the microphone click is of course delayed by the bufferlength of my audiocard, there must be compensation for that somewhere!) ,the delay when i use the midi2table is big and varies (timing jitter). It is in the range 20ms to 40 ms, which makes it pretty useless for triggering notes and even for modulation this delay is at least unsatisfing! (see "keyboard gate versus mic.wav" and "tablet2midi gate versus mic.wav"
2. I recorded the received controller from table2midi as audio signal (i used reakor for it again) and compared it to the recording of the modulationwheel of my midi-keyboard. I tried to make a sweep on both controller of the same duration at around 200-400 ms. I noticed that the table2midi signal is more jagged as the modwheel signal. I guess that the sample rate at which the tablet is sampled at is smaller as the one of my midikeyboard. I wish i can adjust this rate or it should be set to a value below 10ms period. Also the tablet2midi signal has a strange distribution of events. Please have a look at tablet sweep.wav in an editor: At sample 5928 there is an event that looks as if it is much more delayed than the following one for instance. I would expect it to be much more in the middle between the previous one and the following one. Please remember that i made straight sweep by hand. The corresponding recording of the modwheel shows a much more even distribution of the events.
3. See xy.wav: Here i recorded the controller of the xy field. I created jumps by clicking on a upper left position of the tablet, lifting the pen and then clicking on a lower right postion. As you can see in the wav file, the x and y controller aren't updated at the same time, which should be. One would want to sample and hold the controllers on note-on in his aplication. For example x could be pitch, y could be velocity of a note on. That would also require that the midi-gate from tablet2midi should be sent last, means after x and y. I see that this is only a feature that might be interesting to reaktor or max users, where you can tranform midi signals. But it leads maybe to another request: tablet2midi should include a "Keyboard" Object that sends out midi notes with variable pitch, like Ribbon Controller ala R2M from Doepfer! Uuuhhh there is a ton of features just in that Object that comes up in my mind. For more ideas check the R2M Manual which is available on the website: www.doepfer.de
that's it for now.
I hope it's a help.
all the best,
erik
i posted this yesterday. I created a new "topic" which was i guess wrong, as every bug report should go in this topic here. I thought topic is the 'subject' of the report...
first i want to thank you for developing this tool! I always wanted to have something like this. I hope i can contribute to improve it.
I have a Wacom sapphire cte-430. The midi loopback device is midi yoke.
Here are my test/bugs/improvement request.
The mentioned wav-files can be downloaded here: www.errorsmith.de/unlinked/tablet2miditest.zip
I made following tests concerning the timing of table2midi:
1. To test the delay between the actual physical hit of the pen on the tablet and the received midi event, i miked this hit with a microphone, routed it in reaktor via my soundcard and recorded it together with the received midi gate in reaktor as an audiofile. The same i did with my midikeyboard. The audiobuffer of my soundcard (RME Hammerfall) was set to 11 ms. What i meassured disapointed me much: While there is no delay between the micrphone click and the midi gate of my midi-keyboard. (Since the microphone click is of course delayed by the bufferlength of my audiocard, there must be compensation for that somewhere!) ,the delay when i use the midi2table is big and varies (timing jitter). It is in the range 20ms to 40 ms, which makes it pretty useless for triggering notes and even for modulation this delay is at least unsatisfing! (see "keyboard gate versus mic.wav" and "tablet2midi gate versus mic.wav"
2. I recorded the received controller from table2midi as audio signal (i used reakor for it again) and compared it to the recording of the modulationwheel of my midi-keyboard. I tried to make a sweep on both controller of the same duration at around 200-400 ms. I noticed that the table2midi signal is more jagged as the modwheel signal. I guess that the sample rate at which the tablet is sampled at is smaller as the one of my midikeyboard. I wish i can adjust this rate or it should be set to a value below 10ms period. Also the tablet2midi signal has a strange distribution of events. Please have a look at tablet sweep.wav in an editor: At sample 5928 there is an event that looks as if it is much more delayed than the following one for instance. I would expect it to be much more in the middle between the previous one and the following one. Please remember that i made straight sweep by hand. The corresponding recording of the modwheel shows a much more even distribution of the events.
3. See xy.wav: Here i recorded the controller of the xy field. I created jumps by clicking on a upper left position of the tablet, lifting the pen and then clicking on a lower right postion. As you can see in the wav file, the x and y controller aren't updated at the same time, which should be. One would want to sample and hold the controllers on note-on in his aplication. For example x could be pitch, y could be velocity of a note on. That would also require that the midi-gate from tablet2midi should be sent last, means after x and y. I see that this is only a feature that might be interesting to reaktor or max users, where you can tranform midi signals. But it leads maybe to another request: tablet2midi should include a "Keyboard" Object that sends out midi notes with variable pitch, like Ribbon Controller ala R2M from Doepfer! Uuuhhh there is a ton of features just in that Object that comes up in my mind. For more ideas check the R2M Manual which is available on the website: www.doepfer.de
that's it for now.
I hope it's a help.
all the best,
erik
-
- KVRAF
- Topic Starter
- 1511 posts since 2 Jul, 2004
Hi Erik, thanks for the thorough test of the latency.
Looking over my timing code I found that my sample rate was in deed too low. I've made it about twice as fast now. It improves the smoothnes of control changes quite a bit - most of the latency, unfortunately seems to be part of the tablet drivers itself. Tablet 2 midi now has a built in delay of only 3 milliseconds.
I ran some tests of my own and found that my tablet has a huge delay if the pen has been completely removed from the surface - it's like the driver "sleeps" and takes 80-120 ms to wake up. If I run the test by moving the pen across the surface so that it hits the microphone at the same time as it hits a button sending a midi note, the latency is reduced dramatically. I get around 10, max 20 ms of latency.
I've been all over the wintab specs to find any way of reducing the latency, but so far to no avail.
Please test again when a new version arrives. There might be a performance gain for you. Perhaps your tablet control panel has a switch to leave the tablet "always on" or something - could reduce the latency significantly.
Regarding your last comment about sending x, and y coordinates simultaniously, I'm afraid that's impossible - MIDI is serial, meaning one message at a time. There will be a delay of max 3 milliseconds between messages. I will add a switch to bypass the standard MIDI baud rate to speed things up. This will make it impossible for tablet 2 midi to work with external hardware devices though. Software MIDI should not have this limitation, but you never know - they might follow the standard and discard messages when the data rate is too high.
Looking over my timing code I found that my sample rate was in deed too low. I've made it about twice as fast now. It improves the smoothnes of control changes quite a bit - most of the latency, unfortunately seems to be part of the tablet drivers itself. Tablet 2 midi now has a built in delay of only 3 milliseconds.
I ran some tests of my own and found that my tablet has a huge delay if the pen has been completely removed from the surface - it's like the driver "sleeps" and takes 80-120 ms to wake up. If I run the test by moving the pen across the surface so that it hits the microphone at the same time as it hits a button sending a midi note, the latency is reduced dramatically. I get around 10, max 20 ms of latency.
I've been all over the wintab specs to find any way of reducing the latency, but so far to no avail.
Please test again when a new version arrives. There might be a performance gain for you. Perhaps your tablet control panel has a switch to leave the tablet "always on" or something - could reduce the latency significantly.
Regarding your last comment about sending x, and y coordinates simultaniously, I'm afraid that's impossible - MIDI is serial, meaning one message at a time. There will be a delay of max 3 milliseconds between messages. I will add a switch to bypass the standard MIDI baud rate to speed things up. This will make it impossible for tablet 2 midi to work with external hardware devices though. Software MIDI should not have this limitation, but you never know - they might follow the standard and discard messages when the data rate is too high.
http://www.livelab.dk - slice up your life
-
- KVRAF
- Topic Starter
- 1511 posts since 2 Jul, 2004
new version out - big update with incremental / relative midi, tilt, rotation and more
http://www.livelab.dk - slice up your life
-
- KVRer
- 12 posts since 6 Jun, 2004
NRPN works OK now!
But... only if you limit this to one controller only and switch off the rest. It seems all controller numbers now work with an (LSB and MSB) of O, regardless of the CC-number you specify in Tablet 2 Midi, so they mess up each other.
Also, tilt & rotation controllers don't show up in the slider dialog box (altough they are supported my Wacom Intuos).
But... only if you limit this to one controller only and switch off the rest. It seems all controller numbers now work with an (LSB and MSB) of O, regardless of the CC-number you specify in Tablet 2 Midi, so they mess up each other.
Also, tilt & rotation controllers don't show up in the slider dialog box (altough they are supported my Wacom Intuos).
-
- KVRAF
- Topic Starter
- 1511 posts since 2 Jul, 2004
oops - will fix.It seems all controller numbers now work with an (LSB and MSB) of O, regardless of the CC-number you specify in Tablet 2 Midi, so they mess up each other.
hmm... I'll run over the code once more - hard to test when my tablet doesn't support ittilt & rotation controllers don't show up in the slider dialog
http://www.livelab.dk - slice up your life
-
- KVRist
- 332 posts since 23 Apr, 2003
Same experiences here. I can't find them (using Wacom Intuos v1) I am looking forward to this though! Thx ohm.hansvr wrote:Also, tilt & rotation controllers don't show up in the slider dialog box (altough they are supported my Wacom Intuos).
-
- KVRAF
- Topic Starter
- 1511 posts since 2 Jul, 2004
I found the bug hiding the tilt parameters - they were not activated properly. update soon.
http://www.livelab.dk - slice up your life
-
- KVRAF
- Topic Starter
- 1511 posts since 2 Jul, 2004
new update is available.
* Added another 14 bit midi mode (not NRPN) used by Ableton Live, AudioMulch and others
* MouseWheel support in the little number boxes.
* Fixes for Tilt and Rotation support
* Increased tablet buffer to prevent "jumping / skipping" cursor movement
* Manual updated
Everybody using NRPN / 14 bit / relative please let me know how it works out. I tested Ableton Live, ohmforce, Renoise and AudioMulch. Renoise has problems, I emailed one of the devs asking about how they interpret the standards.
* Added another 14 bit midi mode (not NRPN) used by Ableton Live, AudioMulch and others
* MouseWheel support in the little number boxes.
* Fixes for Tilt and Rotation support
* Increased tablet buffer to prevent "jumping / skipping" cursor movement
* Manual updated
Everybody using NRPN / 14 bit / relative please let me know how it works out. I tested Ableton Live, ohmforce, Renoise and AudioMulch. Renoise has problems, I emailed one of the devs asking about how they interpret the standards.
http://www.livelab.dk - slice up your life
-
- KVRist
- 48 posts since 7 Jun, 2005 from Austria
Back in the hopefully right thread. I nailed the jump/jitter problem. It was..the usb hub. The hardware, n o t the programm.
