The rate that G code is processed by the machine ?

So six days thinking about the task I've set myself.
Not sure if I should start a new thread, but I'll continue here untill someone suggests otherwise.

I've looked at the layout of the h.dulcimer and the 'map' of where the hammer actually hits the strings, and it now looks like a simpler approach would be to use three linear axis, each with a hammer solenoid doing the striking.
There would be only 12 striking positions for each axis , each roughly 1.5 inches apart over a 16" track.
Each note woud have a unique X, Y, or Z value, and using an inverse feed rate, I can control the rthymn. I'd use the various other available controls to fire the hammers.

At the moment, I'm going with Axis and G-code because they are familiar to me, and configuring a new m/c shouldn't be too onerous.

However, further down the line I can see a possible difficulty. I currently use 8.04 on a desktop in the workshop(best latency), and I feel reasonably confident that the junk boxes in the workshop will provide me with a working prototype.
But if I want to get out onto the street with this thing, a laptop plus car battery power supply looks like a necessity.

Will this be doable, or should I, at this early stage, go in a different direction to find an equivalent solution ?
Arduino ? Raspberry Pi ? BeagleBoard Black ? or ?

John

If you have a finite number of moves, I'm thinking you could take an old "machine-language approach" and "tune your code" by timing each of the finite moves and storing the results in a table (of #<_named_parameters>) which can then be used to calculate another table of "Perfect" feed rates for each move.

I am not really into Arduinos, but the GRBL G-code interpreter/motion controller seems to be pretty decent.
You might want to check that route.