rsdio's Recent Posts
In case you missed Velocity or the followup report, here's what was shown:
Basic touch detection code has started working on the embedded ARM platform, and things look promising.
Linux has been mentioned a few times here in one thread or another. I'm wondering if anyone has had success porting the open source code to run on Linux.
Doing a little research today, I see that there are basically two options:
1) a kernel driver based on the Linux USB API
or
2) userspace code based on libusb-1.0
Of my many questions, I'm wondering whether this would work in a VirtualBox instance (PC or Mac), or if that might present too many layers. On a related note, if this were done with libusb, I wonder if it would work with libusb on macOS, or if the differences between libusb on different platforms would get in the way.
It looks like libusb-1.0 supports isochronous transfers, offering both synchronous and asynchronous API, so that's promising. I still haven't worked with libusb, so I'm not familiar with its history of support or how mature the various options are. Reading their caveats, I don't see anything obvious that would be an issue.
If anyone has information to share related to Soundplane and Linux communications, please reply here (or point me to existing threads elsewhere). I've had great success using USB directly on a bare metal platform, and - although I avoid Linux for most embedded development - Linux looks like a reasonable platform for someone not running macOS on their computer.
@timoka thanks for the examples and numbers. 10 ms is definitely within the realm of possibility. i read somewhere about gate/trigger pulses as narrow as 50 us, and that would certainly be challenging.
i'm not sure how fancy things will be at the start, but some way to set gate time and amplitude will certainly be prototyped. gate time could either track touch time, or be set to a fixed value, or perhaps be proportional to velocity. gate amplitude could either be fixed at something like 10 V or 5 V or be proportional to velocity, with a built-in minimum to keep modules happy.
velocity on gate is something that seems to be used in the modular world. so long as the gate is greater than the required 2 V or 3 V threshold it will suffice to turn on anything expecting a binary input, and then the exact voltage level would indicate strength via velocity for cv destinations that support it.
personally, i think that pressure may be the most important dimension, so it shouldn't get stuck at an initial value. in contrast, it's fine if the gate gets a steady value.
@timoka Moog S-trigger is not possible, as mentioned before, because it's a current function rather than voltage. Apart from S-trigger, some control over gate length would be nice. If you have example patches in mind that would require a fixed-length trigger, please share them here so we might try them out.
First prototypes, as shown at Superbooth in Berlin, are here!
I thought that folks who aren't in Germany would like a peek.
This is most certainly a prototype. There are a number of details seen in the photo that will change. In fact, this particular face plate has a strange transform on the font that has already been fixed. Component positioning and screw types will be different on the shipping model. The number of LED indicators is planned to change, and my sloppy drilling that can be seen - if you look closely - will certainly not be part of production.
One of those ribbon cables you see behind the module is connected to a MIDI input/output board. This allows testing of the CV outputs independently of the Soundplane touch detection code. I have a simple voice allocation algorithm matched to the four-touch configuration shown, with Velocity, Pitch Bend and Pressure implemented. Paired up with a simple modular synth for testing purposes, everything seems to be working well, with 16-bit accuracy across ten octaves.
As Randy explains on the banner page blog entry, we really tried to pull all of the pieces together before Superbooth, but firmware is always the biggest challenge. We have vendor code for the USB peripheral, my firmware that's been growing as the platform has been built up, and Randy's touch detection that needs to be ported from a laptop computer environment (think: 1 GHz and huge memory) to an embedded environment (120 MHz, 256 KB SRAM). I am certain that we'll be able to get everything working, but at the moment it's MIDI only.
Brian
Is there a specification for how deep a skiff might be?
I did some research a while back, and came up with 40 mm. I also believe that I discovered that the "isms" modules are 41 mm deep.
Are there skiffs that are shallower than 40 mm?
It's not to early to ask, but it's too early to say! We still don't have final hardware, so it's more than just manufacturing delay at this point.
Mockups come in at 8 HP for the basic module, 16 HP for the Chris Harris X special. Just an estimate for now, but that should give you an idea.
New Main Board prototype in hand for Soundplane to CV module. The DAC was simplified by replacing the external reference with a more expensive variation of the DAC with internal reference. Various layout changes were made to improve the mechanical aspects and hopefully prepare for a smaller board when the prototype phase is finished. The on-board 5V supply was beefed up - note the larger, shielded inductor - but it still needs some work.
I have some firmware changes in the queue to facilitate Randy's work. After that, I hope to order final prototypes.
Five new OCTOUCH boards were assembled at the end of May, and test firmware has been developed using MIDI input. The layout has been adjusted to allow for the correct orientation of the capacitors and modular jacks.
Aphex Twin interviews ex-Korg engineer Tatsuya Takahashi and spends some time talking about Scala and editing of Scala tunings on the monologue.
I thought this might be interesting reading for folks working with Scala tunings.
http://item.warp.net/interview/aphex-twin-speaks-to-tatsuya-takahashi/
Blocks sound control experiment with Madrona Labs' Aalto sound effects.
The second hardware prototype revisions are in progress. Five OCTOUCH boards are being assembled as of May 23. Two main boards have been ordered, and parts are on the way; they will be assembled as soon as everything arrives.
While waiting for the second wave of hardware, I will be working on firmware. Abstractions for Gate and CV for X, Y, and Z will be created with control over the Voltage range, scale, and polarity. Touch detection will be integrated as soon as the desktop code is ready.
Thanks for the support, folks. Keep the good ideas and feedback coming.
MIDI and USB-MIDI should be about equally useful. USB-MIDI does not make DIN irrelevant because the timing is tighter for DIN even though the bandwidth is lower. USB-MIDI creates 1 ms jitter due to the USB frame timing. If you run everything through USB-MIDI, then it does alter the timing to a degree in exchange for gaining higher bandwidth.
The USB-MIDI part of the firmware should support both controllers and synths, the only difference being that one is mostly an input and the other is mostly an output.
Thanks, @thetechnobear - I just realized that a USB hub would allow the existing hardware design to support both the Soundplane and a USB-MIDI synth. Just more firmware to write.
Of the USB to MIDI DIN solutions, aren't they mostly USB Devices? I know of one or maybe two USB-MIDI Host to DIN solutions, and I recall them being a lot more expensive than USB-MIDI Device to DIN. It seems moot with hub support, but I'm curious as always.
@chrisharrisx, I'm thinking that one touch per port would allow excellent bandwidth for expression. Another option would be to assign a physical port to a Zone, but I have not studied the typical use cases for Soundplane Zones yet. The latter might be more useful if you want to assign a particular hardware synth to a Zone, assuming that the synth is polyphonic.
@thetechnobear, I don't understand what a USB-MIDI Host would connect to. Usually only MIDI controllers connect to USB-MIDI, but the Soundplane would be the controller in this scenario. I'm assuming that a USB-MIDI Device would actually be compatible with more things, but then we're talking about a computer Host and the whole point of this project is to circumvent the computer that the Soundplane connects to currently.
Another consideration is that this product has devoted its USB port to Hosting the Soundplane, and the kinds of CPU chips that can handle two USB ports are typically more expensive than those that handle just one USB port, not to mention the extra USB jacks that would be needed.
If by iHost you mean an interface to iOS, then that could be expensive considering the various hurdles that need to cleared in order to talk to iOS using Apple's proprietary Device-to-Host switching protocol. Apple has something like USB OTG, but the protocol is different for an iOS Device. I think I'll understand what you're thinking of if you mention specific pieces of gear that you'd want to hook up, because then I could investigate the details.
Thanks for the feedback!
I'm seriously considering RTP-MIDI, but I have no idea how much firmware development effort that will require. If completed, RTP-MIDI should allow a lot of options that do not require dedicated ports.
Thanks, Chris. Would you be interested in 4-out 1-in, or 3-out 2-in MIDI? In terms of panel space, they're the same.
Still looking for front panel makers with quantity discounts.
Thanks for the input, kirr. I had the impression that Front Panel Express prices did not allow volume discounts, so they're all technically "custom" panels. I probably have a lot to learn about sourcing panels for mass production.
Thanks, sequencersampler.
My current thinking is to make it easy on the customer and provide an 8HP panel for 2 touches as the primary model. We assume that will be the most common desire, so it will come as a single module that's ready to go.
The main board supports up to 10 touches, which seems a reasonable limit for humans. How to deliver that is an unanswered question.
Like most modules, there will be separate circuit boards behind the front panel, but I wouldn't expect customers to deal with interfacing individual boards unless that's the only option. Since I doubt we can find bulk discounts on the panels anyway, customers who want more than 2 touches may get a custom front panel that combines everything. For those of you that want MIDI, those jacks could be to the left or right of the CV and main USB sections, but that could affect the length of the ribbon cables. No promises that every combination will be available, but that's my idea so far.
My primary reason for separating the CV board from the main board was to reduce the number of PCB layouts across the various permutations. It should be a bit less expensive to make these submodules all the same and avoid the high prices of low quantity orders.
I briefly researched putting a single touch (4 CV) on the main module, but that ended up being way too tight for one board, so the next logical option was dual-touch units (8 CV, as shown).
Doepfer makes a few expander modules that are only 2HP wide, but that's just too narrow for the octouch boards. If available separately, the octouch would be a 4HP module, but it might actually make more sense to do custom panels that combine the desired number of touches with optional MIDI.
I think that the challenge will be to figure out what the second most common combination of features might be. I think it will be more affordable to have just one or two standard models to make production go more smoothly, with the option of more expensive custom design for customers who need more than the basic model. I think that some cost analysis and a survey would help.
Thanks, Chris. I see now. Maybe a rotary switch or a couple of toggles. A quick thought is that one toggle switch could select between canned zone maps versus custom, and a second toggle switch could select between an A versus B option of each. If there are more than two custom presents, maybe a button with LED indication of the present number.
I would like to ask folks: Do you need just a couple of presets? Four? More? I mentioned the classic 7-segment LED array, but that idea was not popular (seen as too retro). Another minimal option might be two to four LEDs that could indicate the preset number without going to a full display.
I'm floating wild ideas now while waiting for more input from users. I've started design of the CV board, so the main board won't be started for a bit. The main board is where preset selection and other UI would live.
@timoka, thanks for the feedback.
I'm fairly certain that trigger functionality and timing could be handled in firmware, including inverted (negative polarity) for compatibility with some, e.g. DotCom, modules. I understand that duration is a consideration for getting a good sound from a low pass gate, so time would be a configuration setting.
Moog S-trigger cannot be supported without significant hardware changes, so an external converter would be needed for that.
New update - OCTOUCH Soundplane CV expander board working!
I'm sure this is the piece that folks have been waiting to see. The pictured board supports a pair of Soundplane touches, with Gate/X/Y/Z outputs for each.
You'll see a couple of LED indicators above each group of four 1/8" CV outputs.
The top jack is intended as Gate, and is very flexible in terms of matching required voltages for various synthesizer brands - including the option for Velocity on Gate (a rare thing that I've actually heard of being used). The associated Gate LED is On or Off to indicate the status of the Gate signal. Currently, the Voltage threshold for that LED is set to 1.5 V since I believe that will work for all necessary settings. The actual CV output signal on the Gate Voltage jack can be as high as 10 V if your synth needs that much.
The next three jacks are for the X, Y, and Z dimensions of the associated Touch. These can be positive-only (probably appropriate for Z-pressure) or bipolar (for X-pitch and/or Y-timbre). The second LED is hard-wired to the Z dimension and lights up in proportion to the positive Voltage strength. The intention is to give feedback about the pressure.
The firmware will allow customization of Voltage ranges to suit various modules, but will have a decent default setting for folks that just want to play. The main board supports more than one of these CV expansion boards for folks who want more than two touches.
For simplicity, the LED functions are set in hardware because I wanted to avoid having complex control signals between the main CPU and the CV expansion just for LED indicators. In particular, I did not want to send high-frequency high-current PWM signals for LED dimming because these boards are all inside a modular synthesizer. I figure it's better to simplify the LED features and focus on good sound without buzzing interference. I also decided not to try to cram four LED indicators per touch, even though that might have been "cool." Although there's room for more LED indicators, I'm reluctant to add the additional circuitry in a product where we should be focused on sound sculpting.
If anyone has comments on these features, please share. It's not too late to change certain details or perhaps add features within reason. I think I've given a hint or two about my design philosophy.
p.s. the code name, octouch, combines the Greek prefix octo- with our favorite word, touch. the assembler mispelled this as Oc Touch, which had me wondering if I could think up another meaning for the letters, but I haven't come up with anything further.
Hi Alex. Glad to see the interest.
Keep in mind that Kickstarter only helps round up the money, with a little social networking promotion in the process. Sadly, Kickstarter does nothing to help with the technical process of design-for-manufacturing. I follow a few Kickstarter projects where it's clear from the updates that they have no real product yet and are just starting on the manufacturing design. The whole design process tends to take the same amount of time, with or without Kickstarter. I think that Kickstarter is better for less expensive products that are more popular, and will therefore be manufactured in much higher quantities. More people pitch in small amounts and it eventually adds up.
Madrona Labs starts by solving the technical details and then rounds up the money afterwards. I personally think that's a better approach to designing around new ideas that aren't necessarily cheap. I'm sure that Randy can find a way to move forward if anything like funding gets in the way.
Quick news update: MIDI expansion hardware validated... before moving on to the more complex output features.
Most modular users probably will not need MIDI out (or in), but it seems like a good plan to design the system to handle it as an option. At the very least, the polyphonic features of the Soundplane will be easier to support over MIDI. If MIDI controller messages eat up too much bandwidth, the multiple MIDI ports allow the touches to be sent over separate cables or divided by zones or other schemes that we come up with.
The displayed board has three MIDI outputs and two MIDI inputs. Another board design has four MIDI outputs and one MIDI input. Both boards offer the option to convert the last output to MIDI thru, for the rare users that might need it. The current designs pack five MIDI jacks into the standard Euro height, but if user input suggests that having four MIDI jacks spaced further apart is a better idea, then the boards could easily be altered before production. Four of these expansion boards together, connected to the main board, allow the full potential of eight MIDI outputs and eight MIDI inputs.
As mentioned in earlier installments, MIDI is included because it's easy to support and should be available as an option for those who need it. As part of the Hardware Validation phase, I wanted to briefly test the MIDI subsystem to make sure there are no hardware changes needed on the main board. A quick test has my 1986 vintage Akai VX90 happily producing sounds, controlled by MIDI from the prototype Soundplane host.
The next installment should be the CV Output expansion hardware, which will be part of the base system. I hope to have that update here soon.
@morgang - I don't have Reaktor, but I assume that it would be easier to support the Soundplane via MIDI. In the MIDI world, each touch would be a separate MIDI Channel, and then Note On/Off, Pitch Bend, Aftertouch, and Continuous Controllers would allow the Soundplane to control a lot of parameters in Reaktor without as much effort on your part.
The issue with OSC is that there is no standard way to connect a controller with a sound-generating device. In the monome world, there are a set of 2D messages, but they do not support pressure or the other dimensions of the Soundplane. Randy's t3d protocol is not specific to the Soundplane, but I don't see Reaktor supporting this natively without some work.
Granted, MIDI doesn't fully support a non-keyboard controller like the Soundplane without requiring a few settings to be tweaked (primarily, making sure the Pitch Bend range is set high enough to allow a Soundplane touch to extend across most of the surface), but I've been able to get vintage synths to do everything I need (except bend beyond 2 octaves).
More news on the Soundplane to CV module.
The second phase was hardware design and prototyping.
There are many embedded processors and I did not want to get too deeply into the hardware design process until after I was reasonably sure that the chosen one could handle the task. I recall some 8-bit MCU USB peripherals are limited to a maximum of 256 bytes for isochronous packets, while the Soundplane uses two endpoints of 388 bytes each. The proof of concept phase mentioned last week convinced me that the TM4C1294 can handle the full bandwidth, which makes sense given the 32-bit ARM architecture.
Cortex-A chips - the opposite end of the spectrum - are significantly more expensive, pull vastly more power from an already challenged modular power supply, and are really only necessary when you need serious graphics processing and full operating system support. You will not find a Cortex-A chip for as little as $7, so I am happy with the Cortex-M4F.
The next task after settling on a chip was to arrange all of the external connections to fit the specific GPIO ports. With 128 pins, 90 of which are GPIO, there are many interfacing options. Starting with a system design at a block diagram level, I grouped similar control signals together on the same port to simplify the firmware, and with so many GPIO options I was also able to move functions around the chip to locate them near subsystem groups on the PCB. Despite the 32-bit nature of ARM, the 15 ports are all 8 bits or less, which is a little different from, e.g., the XMOS chip architecture.
A side effect of designing the system first is that many of the expansion boards went through layout and prototyping before the main board. The advantage of handling them first was that they were very quick to design and I could work on the main board while waiting for the expansion boards to come back from fabrication and assembly. Future installments will discuss those.
I then completed the main board PCB design and reviewed it several times before beginning layout. You will see in the photo that it has the requisite Euro rack power connector. Peripherals include a rotary encoder, potentiometer, button, several LED indicators, and the obvious USB A Host port. Besides the many anticipated expansion connectors such as octal MIDI I/O, there are also a couple of quad synchronous serial port headers. Those SSI peripherals may never be used, but they would allow for serious high-speed data connections to other subsystems.
Basic firmware is up and running on this main board and communicating with the Soundplane. A lot more work is needed on the firmware, however, to implement all of the subsystems and get them working together. Obviously, besides the foundational basics, the first test will be to track at least one touch and generate a set of Gate and X+Y+Z Control Voltages that bring Soundplane performance gestures to life on a modular.
There is no particular schedule for future installments of these reports, but I think there should be time for me to put out a few more in the coming weeks.
The TT code has been open source all along for the purpose of maximizing compatibility with as many platforms as possible. Randy is currently working on optimizations for that code which should help, as you say.
The BBB/Bela Cortex-A9 seems to be geared towards a higher-level Linux system with higher latency, while offering easier application development due to the well-known platform. This Cortex-M4 platform will not be based on Linux, and so the latency should be as low as possible for hardware - unfortunately, low-level firmware is a bit more difficult to master although the performance makes it worth the effort.
Hello all,
Yes, there is a bit of news... enough that I'll break it into two installments.
The first phase was research and proof of concept.
The Soundplane poses a bit of a challenge because it requires isochronous USB, and quite a bit more payload than some embedded processors can handle. The project got started with a Texas Instruments LaunchPad : the EK-TM4C1294XL. The chosen processor is an ARM Cortex M4, and it seems to have what is needed. There is floating point support and the ability to host the Soundplane.
You'll see in the photo that an adaptor was needed from the tiny USB connector on the LaunchPad to a USB A socket as needed by the Soundplane. A quick bit of development in Code Composer Studio resulted in firmware that can power up and communicate with the Soundplane, and it doesn't seem to be dropping any packets. In addition, crude touch detection seems to indicate that there are no lost packets, so full bandwidth is working.
You'll also see a tiny SMD capacitor soldered to the through-hole expansion pads. This was necessary to handle the current draw of the Soundplane at 230 mA, which is almost half the limit of USB.
After the first phase, significant time was spent designing custom hardware for a modular environment with precision D/A for CV outputs.
Stay tuned for the second phase.
Dangerous Prototypes is also a good site with lots of open-hardware and open-source projects. It's basically Hack-a-Day for electronics design.
http://dangerousprototypes.com/