It is possible to get pianoteq work with good performance on a Gumstix Overo Computer-on-Module with Linux. It es has only 600 Mhz but is a very small system with Texas Instrument's OMAP® 35x processors and preflashed Linux. See here www.gumstix.com - They tell about a "laptop-like performance" up to 1200 Dhrystone MIPS" - whatever this means.
wow, these things are awesome!
seems 1200 is an order of magnitude lower than most regular laptops with some flavor of core2duo tho. They're well beyond 10,000, actually over 20,000 too. Problem is, dhrystone mips seems to be a unit for measuring not so powerful devices (like ARM chips for pda) so it's hard finding figures... I tried finding numbers from Atom chips so we can compare it with netbooks, but couldn't find any figures.
I do have a feeling that 1200 isn't much. Still, these things seem really cool!
The size and the preflashed linux makes this sound good. I worry about the bus speeds and general through-put though. 600 mhz isn't much these days. And it only has 256 megs of RAM. Intended for running an embedded version of Windows CE, apparently. There's an add-on board for audio. (http://www.gumstix.com/store/catalog/pr...cts_id=158) Seems as though there's a lot to learn about these boards.
But imagine what would be possible if it can do audio, or if they could later get the speed up--a small box (quarter rack sized?) that could just plug into a midi keyboard directly, with Pianoteq or I guess other vsti's and sample libraries loaded. You could have a monitor and touch pad attached for editing, or with a midi keyboard with lots of knobs, just have all of the cc's set up so that there would be no need for the monitor and touchpad. Seems a little underpowered for now, though.
I see a couple immediate problems.
It looks like it's an ARM based processor, so they would probably have to compile PianoTeq for ARM. I'm no expert, but I think that even though ARM is similar to x86, code can't run on both natively without modification.
Also, pretty obviously, they're not very powerful compared to even a normal everyday laptop. The Dhrystone measurement does not include floating point performance (wikipedia is our friend), and I recall hearing that PT absolutely requires good floating point performance. The ARMv7 (aka Cortex) does have floating-point capabilities though, so it might technically be possible to run an ARM version of Pianoteq, if they ever made it. It would probably be best if it were running alone, without the burden of an actual OS. Interesting.... Still, an embedded, standalone Pianoteq device would probably be better off running a higher-power processor not designed for mobile devices.
The Cortex processor looks very interesting. It's amazing how much power they can get out of such a small and low-powered device. You'll definitely be seeing these in smartphones, etc. But as far as raw performance, it's still not in the same league as the simplest desktop processor.
EDIT: I don't mean to be so pessimistic about ARM based PianoTeq. The architecture itself has nothing that would prevent it from running well. It's just the goals they have when they design ARM processors. If they made an ARM processor that wasn't so concerned about low power usage, it could easily be made fast enough to run this kind of program.
EDIT #2: I just saw that this exact ARM core that the Overo has (Cortex-A8) is what the new iPhone 3G S has. Interesting.
After reading the specs more closely, I see that it has a slot for a sd card and supports 256 megs of flash ram, so both data and programs could reside on the board itself.
PianoTeq might be out of the question, but I wonder what else might be put on one of these. Hardware synths used to have a much less powerful system than this, with much lower memory requirements and small sample sets. Would it be possible to put something like a Proteus 2000 module on one of these? While giving the user the ability to load new samples by way of the sd card? Or how about just a basic soundfont or sfz player? Hm... Is there a good linux soundfont player that could be loaded? Groovy--your skills and knowledge are needed here.
(I'm not sure of the memory limits for the micro sd cards, but I'm sure they can hold more data than many of the current stage pianos. And some of these small boards have a usb port. I guess a flash hard drive could be attached, too.)
Or how about just a basic soundfont or sfz player? Hm... Is there a good linux soundfont player that could be loaded? Groovy--your skills and knowledge are needed here.
Sorry, no expert here ... I'm just standing on the shoulders of giants and used the tons of information from the internet about realtime-linux. - Concerning this thread I forced my eee-pc down to 800 MHz to see what's possible with a slow CPU.
cpufreq -set -c 0 -g conservative
cpufreq -set -c 1 -g conservative
Load-headroom enough to play the electric-pianos and even the acoustic piano M3. But with 800 Mhz the audio load of piantoteq is higher, more uneven and has more spikes, than with 1600 MHz. A few notes with "C3 Solo recording" at 800 Mhz --> worse overload. Those gumstixs have 600 Mhz if I remember correctly (and just a single core?). Not impossible to drive physical modeling with it, but on the edge I guess. Debian-Linux runs on nearly every architecture (one of its strengths) which means on ARM CPUs also. But I don't now, if realtime-kernel-patches are available for ARM. And pianoteq is no open source, so it can't be compiled for ARM (by others than modartt).
A cheap laptop or a netbook seems a better choice to me.
- groovy
Still curious about what could be done along the lines of recreating an old school type of sample player with one of these. May be the wrong forum, though...Hard not to want something along the lines of one of the later Proteus modules or say an Ensoniq ZR-96 that you could carry around in your pocket and just plug into any keyboard's usb port. (My impression is that these boards don't even require a fan.)
And I sometimes wonder if Pianoteq could ever generate "hard presets" that would reduce the number of calculations needed--now, given the many variables, I would imagine that there are many if-then statements that have to be gone through, with the results calculated in real time as the notes are played. Would there be a way to instead compile the sound still further? In other words, the user, after setting the parameters to whatever were wanted, could generate a preset that was locked down, with no variables to be looked up--the program wouldn't have to calculate the if-then statements. The program would simply always play sound X whenever a note was hit at a given velocity. (The other variable would be the pedal position.) Would a slower cpu be able to drive hard presets such as these? Or am I misunderstanding the programming situation entirely? Does looking up the variables add a negligible load to the processor, compared to just creating the sound? (Or for that matter, does saving a preset already eliminate the need to read the variables\if-then statements?)
Jake Johnson said:
"And I sometimes wonder if Pianoteq could ever generate "hard presets" that would reduce the number of calculations needed--now, given the many variables,"
I think the 'Effects Panel' could have its own dedicated screen: like the Microphones from the 'Output Panel'. This could then be more elaborate, incorporating the presets and other extended effects.
Then you could apply the preset the any piano rather than create another one.
Who'd be a programmer?
Jake Johnson said:
"And I sometimes wonder if Pianoteq could ever generate "hard presets" that would reduce the number of calculations needed--now, given the many variables,"
I think the 'Effects Panel' could have its own dedicated screen: like the Microphones from the 'Output Panel'. This could then be more elaborate, incorporating the presets and other extended effects.
Then you could apply the preset the any piano rather than create another one.
Who'd be a programmer?
I think that would mean making the effects section a separate program, almost as though it were a separate vst effect that came second in a chain. Don't know what that would do for reducing the cpu load still further.