The pepper pad is a linux-based wifi touchscreen tablet. Compared to newer sleek devices it may seem clunky, but the screen is a nice size for touch interactivity and the odd split qwerty keyboard offers convenient tactile control.
Pepper pad can run VNC remote desktop client, so it can be used as a wireless touchscreen interface to any software on any platform.
In my own projects I used the pad to wirelessly control GDAM - dj mixing from around the room (tactile keys mapped to transport, looping, and effects functions), sequencers and break resequencing that anyone could try.
For Share I used the pad as a touchscreen interface to open source DAW Ardour running on an OSX tower. Musicians plugged into our mixing system from stage boxes situated around the venue, and I could monitor levels and adjust settings from whereever they were.
Showing posts with label interface. Show all posts
Showing posts with label interface. Show all posts
Saturday, January 24, 2009
Thursday, November 8, 2007
Casio PG-380 program change
The Casio PG-380 midi guitar, and midi guitars in general, can be great interfaces. In fact, it's my interface of choice for my main music project. But the PG-380's interface for MIDI Program Change is baffling.
There is a 2-LED display which shows the current program. But this does not display the program in binary, octal, hex, or decimal. Rather it displays hexal, the low half of octal values but counting from 1; each LED displays 3 bits, counting from 1, with values 1-8. Apparently the designers thought counting from 0 would be confusing, but didn't go all the way making it display proper decimal (counting from 0 or 1) The default program, binary/decimal 0 according to MIDI spec, is displayed as "11": each of the 3-byte units is 0, so the LED displays two 1s. 11-18 progress as expected, representing MIDI decimal 0-7. The next program, represented with as a decimal 8 (9th program counting from 0) in MIDI spec is displayed as "21"... to reconstruct their logic, the binary representation is 00001000 grouping it into the 3-bit units that drive the LED's yields 00 (001) (000) which is 0 (1) (0). But Casio thinks 0s are confusing, so they add one to each and display "21". There are 8 buttons for entering the program, labeled 1-8. The labeling corresponds to the LED display; each represents 3 bits, counting from 0. The first press sets the the "high" unit, bits[3-5] the second press sets the lowest 3 bits. The maxium program, decimal 63 binary 00111111 grouped (00) (111) (111) equivalent to (0) (7) (7) is displayed as "88".
Phew! Translating between the the displayed values and the actual equivalent bytes is an obnoxious ordeal that slows down creation of MIDI binding patches. The display logic is too tied to the underlying binary system, but oddly they didn't go to decimal, counting from 0 or 1. Instead it sits in-between, with its own unique mapping scheme between the displayed value and the actual MIDI byte. Although I'm not an expert on old MIDI hear, I've never seen another piece of gear using this odd scheme. I imagine there is some other Casio gear from the era which displays in a similar way. Horribly non-intuitive and cumbersome.
There is a 2-LED display which shows the current program. But this does not display the program in binary, octal, hex, or decimal. Rather it displays hexal, the low half of octal values but counting from 1; each LED displays 3 bits, counting from 1, with values 1-8. Apparently the designers thought counting from 0 would be confusing, but didn't go all the way making it display proper decimal (counting from 0 or 1) The default program, binary/decimal 0 according to MIDI spec, is displayed as "11": each of the 3-byte units is 0, so the LED displays two 1s. 11-18 progress as expected, representing MIDI decimal 0-7. The next program, represented with as a decimal 8 (9th program counting from 0) in MIDI spec is displayed as "21"... to reconstruct their logic, the binary representation is 00001000 grouping it into the 3-bit units that drive the LED's yields 00 (001) (000) which is 0 (1) (0). But Casio thinks 0s are confusing, so they add one to each and display "21". There are 8 buttons for entering the program, labeled 1-8. The labeling corresponds to the LED display; each represents 3 bits, counting from 0. The first press sets the the "high" unit, bits[3-5] the second press sets the lowest 3 bits. The maxium program, decimal 63 binary 00111111 grouped (00) (111) (111) equivalent to (0) (7) (7) is displayed as "88".
Phew! Translating between the the displayed values and the actual equivalent bytes is an obnoxious ordeal that slows down creation of MIDI binding patches. The display logic is too tied to the underlying binary system, but oddly they didn't go to decimal, counting from 0 or 1. Instead it sits in-between, with its own unique mapping scheme between the displayed value and the actual MIDI byte. Although I'm not an expert on old MIDI hear, I've never seen another piece of gear using this odd scheme. I imagine there is some other Casio gear from the era which displays in a similar way. Horribly non-intuitive and cumbersome.
Thursday, March 1, 2007
Video Playback: volume compression
I live in an apartment, the walls are thin, and I enjoy my TV and movies late at night. The dynamic range is way too high, some dialogue is barely audible at full volume but sudden action explodes in a frantic dive for the volume control. Volume normalization can mitigate this somewhat at extreme settings, but it is imprecise and inaccessible.
A better model: interactive volume mode, simple controls which adjust expander / compressor / limiter to intuitively adjust dynamics. If I can't hear the dialogue, I indicate "too quiet". This boosts the input volume or otherwise adjust the dynamics to boost quiet parts. After the first car crash, I indicate "too loud". This looks at the maximum output volume during the last 10 seconds, and adjusts the compressor/limiter to guarantee that nothing will produce output louder than 90% of that. The system would quickly be tuned to the content and my environment.
A better model: interactive volume mode, simple controls which adjust expander / compressor / limiter to intuitively adjust dynamics. If I can't hear the dialogue, I indicate "too quiet". This boosts the input volume or otherwise adjust the dynamics to boost quiet parts. After the first car crash, I indicate "too loud". This looks at the maximum output volume during the last 10 seconds, and adjusts the compressor/limiter to guarantee that nothing will produce output louder than 90% of that. The system would quickly be tuned to the content and my environment.
Wednesday, February 28, 2007
HID
The Human Interface Device standard for USB devices is great. The obvious appeal of using them as controllers: there are a huge number of cheaply available keyboard, mice, trackpads, joysticks, jog wheels, etc, all of which can be understood without individual drivers. However using them as controllers is not straightforward because most audio software does not accept joystick input, and mice and keyboards just duplicate the normal mouse and keyboard.
In Linux, I wrote a GDAM input plugin for reading USB HID events. USB events show up on /dev/input/event* (if you have your kernel configured correctly, but these days it seems to be the default) The event interface is also great: you get 3 bytes, the first is event type (button vs axis vs relative etc) second is index (256 of each type max per device) 3rd is value. Implementing the OSX version involved many lines of dynamically allocating objects based on how big they were in the current version of OS.... linux was dead simple.
Recently revisiting some HID controllers, they were less convenient than MIDI. In particular, if I unplug the device /dev/input/eventN disappears and I get read errors. If I replug I have to reopen device. So I made a HID -> MIDI driver for linux. It hotplugs, and any USB HID device plugged in becomes a virtual ALSA MIDI port. So far I'm translating key and button presses, and absolute values (faders, analog joysticks) into MIDI notes and CC's. I haven't decided the best way to translate relative (mouse, touchpad) events into MIDI, there is no clear match. I refuse to convert to absolute by driving a virtual CC because that would be limiting. I may send note on with different velocities, or set CC value for each relative event but those are non-standard uses.
Now, using qjackctl's patchbay to automatically restore MIDI routing, I can replug my HID controllers at will without doing a thing in software. Instead of working through a plugin specific to my software, the MIDI can be used with any software or even sent over a MIDI cable to drive hardware.
I made a quick GDAM binding file to make the MIDI notes correspond to qwerty layout. My laptop keyboard may or may not be implemented via USB, but it does show up in /dev/input/event* so I can run my driver on it. Now all my typing is rendered rhythmically and melodically. I've enjoyed some of the riffs that emerged while I code, newlines and braces resolve nicely.
In Linux, I wrote a GDAM input plugin for reading USB HID events. USB events show up on /dev/input/event* (if you have your kernel configured correctly, but these days it seems to be the default) The event interface is also great: you get 3 bytes, the first is event type (button vs axis vs relative etc) second is index (256 of each type max per device) 3rd is value. Implementing the OSX version involved many lines of dynamically allocating objects based on how big they were in the current version of OS.... linux was dead simple.
Recently revisiting some HID controllers, they were less convenient than MIDI. In particular, if I unplug the device /dev/input/eventN disappears and I get read errors. If I replug I have to reopen device. So I made a HID -> MIDI driver for linux. It hotplugs, and any USB HID device plugged in becomes a virtual ALSA MIDI port. So far I'm translating key and button presses, and absolute values (faders, analog joysticks) into MIDI notes and CC's. I haven't decided the best way to translate relative (mouse, touchpad) events into MIDI, there is no clear match. I refuse to convert to absolute by driving a virtual CC because that would be limiting. I may send note on with different velocities, or set CC value for each relative event but those are non-standard uses.
Now, using qjackctl's patchbay to automatically restore MIDI routing, I can replug my HID controllers at will without doing a thing in software. Instead of working through a plugin specific to my software, the MIDI can be used with any software or even sent over a MIDI cable to drive hardware.
I made a quick GDAM binding file to make the MIDI notes correspond to qwerty layout. My laptop keyboard may or may not be implemented via USB, but it does show up in /dev/input/event* so I can run my driver on it. Now all my typing is rendered rhythmically and melodically. I've enjoyed some of the riffs that emerged while I code, newlines and braces resolve nicely.
GDAM: scratching
Scratching in GDAM is based on the Bender plugin - an inline filter which keeps a large buffer of audio and allows playback at any speed, backward or forward, from any point in the buffer. If you are familiar with the Buffer Override VST filter, I am told it uses this technique.
Bender plugin can manage the input to the buffer in various ways; it can keep the input at full speed, advance only when needed, or even drop bars of music to keep playing in beat, without making progress through the song.
Scratching in GDAM allows the user to set certain cuepoints in the audio stream, and jump to them, while playing backward or forward at any pitch. The ability to teleport between point in the audio stream breaks a major limitation of vinyl scratching: to get from one part of a sample to another, the vinyl DJ has to move the needle along the groove. To get there fast, the record spins fast and the sample plays at a higher pitch. The scratch DJ may selectively mute parts of the scratch to obscure some of the "incidental" pitch, but there is noneless a very rigid relationship between where in the sample you can be, how fast you are moving through the sample and what the pitch is at any moment.
GDAM's ability to jump to marks within the sample allows different parts of a sample to be played back-to-back in a way that is impossible in vinyls. On top of Bender, it is even possible to switch seamlessly into timestretching and pitch shifting, breaking the speed/pitch relationship. In theory a bit like going from pushing a car on a flat track to flying uninhibited through 3d space.
Another technique is to take timestretching to the extreme that position does not progress forward or backward on its own. It plays a microloop of the current position, and you can drag the playhead back and forth while changing the pitch independently. You can do a record stall in place by fading pitch down to 0, scratch back and forth at any consistent pitch, and all kinds of other tricks impossible with vinyl.
For MIDI control for scratching I like to use the pitchbend wheel - pulling it towards me to rewing and pushing it away from me to play > 100% speed. A nice thing about the pitch bend wheel is that it returns to its detente position when you remove your hand, in the same way that a record returns to full turntable speed when you remove your hand from it.
So of course pitchbend 0 always mapped to 100% speed. But I have a number of different mappings for the rest of pitchbend range. The two most common are 1) pulling back from detent slows from 100% to stalled then increases to -200% or -400% at pitchwheel full back 2) pulling back from detente instantly trigger 0% and from there increases to -400%. 1) gives a snappier scratch, 2) is useful if you want to stall a record but GDAM also offers plugins which do this perfectly so it didn't get as much use.
Although I've often dropped a bit of scratching into sets and demos, I never really spent time developing routines and pushing the limits of what is possible.
Bender plugin can manage the input to the buffer in various ways; it can keep the input at full speed, advance only when needed, or even drop bars of music to keep playing in beat, without making progress through the song.
Scratching in GDAM allows the user to set certain cuepoints in the audio stream, and jump to them, while playing backward or forward at any pitch. The ability to teleport between point in the audio stream breaks a major limitation of vinyl scratching: to get from one part of a sample to another, the vinyl DJ has to move the needle along the groove. To get there fast, the record spins fast and the sample plays at a higher pitch. The scratch DJ may selectively mute parts of the scratch to obscure some of the "incidental" pitch, but there is noneless a very rigid relationship between where in the sample you can be, how fast you are moving through the sample and what the pitch is at any moment.
GDAM's ability to jump to marks within the sample allows different parts of a sample to be played back-to-back in a way that is impossible in vinyls. On top of Bender, it is even possible to switch seamlessly into timestretching and pitch shifting, breaking the speed/pitch relationship. In theory a bit like going from pushing a car on a flat track to flying uninhibited through 3d space.
Another technique is to take timestretching to the extreme that position does not progress forward or backward on its own. It plays a microloop of the current position, and you can drag the playhead back and forth while changing the pitch independently. You can do a record stall in place by fading pitch down to 0, scratch back and forth at any consistent pitch, and all kinds of other tricks impossible with vinyl.
For MIDI control for scratching I like to use the pitchbend wheel - pulling it towards me to rewing and pushing it away from me to play > 100% speed. A nice thing about the pitch bend wheel is that it returns to its detente position when you remove your hand, in the same way that a record returns to full turntable speed when you remove your hand from it.
So of course pitchbend 0 always mapped to 100% speed. But I have a number of different mappings for the rest of pitchbend range. The two most common are 1) pulling back from detent slows from 100% to stalled then increases to -200% or -400% at pitchwheel full back 2) pulling back from detente instantly trigger 0% and from there increases to -400%. 1) gives a snappier scratch, 2) is useful if you want to stall a record but GDAM also offers plugins which do this perfectly so it didn't get as much use.
Although I've often dropped a bit of scratching into sets and demos, I never really spent time developing routines and pushing the limits of what is possible.
STC-1000
Another promising device, a pressure-sensitive Kaoss Pad without the audio circuitry or flashing lights. Elegant design. Has MIDI but no USB - less convenient but it is guaranteed to be standard compliant (kinda...)
When I received the unit in the mail, I eagerly hooked it into GDAM, dumped the MIDI, and made a binding file linking the MIDI signals to some effect parameters. But playing with it, something was not right... instead of sending straight X/Y/Z (pressure) coordinates, it sent relative values! This may help to adjust parameters smoothly, but it prevents the obvious application of tapping the center of the X axis to get 50% on parameter, far left to get 0%, etc. Again, relative motion with different levels of sensitivity, soft pickup, and all kinds of other behaviour would have been possible in standard software if they had just sent the pure XYZ coordinates as CC or Pitch Wheel (touchscreen resolution is greater than 7 bit CC value).
The company promised applications for configuing the unit, and the pure coordinates were packed into MIDI sysex data, but as I had no immediate need for the controller I didn't write a driver. Judging by the response to my post to their message board, and other posts, I was far from the only person disappointed by this. When I visited their site recently they seemed to provide software for programming the unit.
When I received the unit in the mail, I eagerly hooked it into GDAM, dumped the MIDI, and made a binding file linking the MIDI signals to some effect parameters. But playing with it, something was not right... instead of sending straight X/Y/Z (pressure) coordinates, it sent relative values! This may help to adjust parameters smoothly, but it prevents the obvious application of tapping the center of the X axis to get 50% on parameter, far left to get 0%, etc. Again, relative motion with different levels of sensitivity, soft pickup, and all kinds of other behaviour would have been possible in standard software if they had just sent the pure XYZ coordinates as CC or Pitch Wheel (touchscreen resolution is greater than 7 bit CC value).
The company promised applications for configuing the unit, and the pure coordinates were packed into MIDI sysex data, but as I had no immediate need for the controller I didn't write a driver. Judging by the response to my post to their message board, and other posts, I was far from the only person disappointed by this. When I visited their site recently they seemed to provide software for programming the unit.
USB A
The worst plug design I've come across. The team that approved the design should be ashamed. It is easy to try to plug in upside-down, and impossible to tell the difference in the dark or if you are pluggin in by touch.
USB B is much better, the difference between square and cut corners is easy to feel in both socket and plug, and it doesn't almost go in if you have it wrong.
Why are A/B different to begin with? Allowing for different form factors allow you to keep up with the times, eg mini-usb ports on cell phones and other tiny devices. And certainly A is an easier fit into the edge of a powerbook than B. But I suspect the standard of A on hosts and B on peripherals was adopted so that people were less likely to plug in hubs the wrong way. If the host, hub, and peripherals all used B then the user would have to pay attention to the routing, the ins and outs. But because in/out ports are differentiated by shape, it is impossible to connect peripherals through a hub incorrectly.
USB B is much better, the difference between square and cut corners is easy to feel in both socket and plug, and it doesn't almost go in if you have it wrong.
Why are A/B different to begin with? Allowing for different form factors allow you to keep up with the times, eg mini-usb ports on cell phones and other tiny devices. And certainly A is an easier fit into the edge of a powerbook than B. But I suspect the standard of A on hosts and B on peripherals was adopted so that people were less likely to plug in hubs the wrong way. If the host, hub, and peripherals all used B then the user would have to pay attention to the routing, the ins and outs. But because in/out ports are differentiated by shape, it is impossible to connect peripherals through a hub incorrectly.
Subscribe to:
Posts (Atom)