j4cDAC: a new open-source DAC project

[JohnYayas]

not knocking it, just trying to figure out how you can have your cake and eat it too .

When people design Spaghetti shows that take whatever ILDA files they have, combine them, apply effects, etc. They don't know if they were ever optimized, what speed they should be shown at, etc. Once you start combine frames and convoluting them, all bets are off as to what point rate is optimal for them. So, Spaghetti does it's own optimization and chooses a point rate that is appropriate for the frame and for the scanners. Perhaps not the perfect situation but it works well in my application. The pros outweigh the cons.

[j4cbo]

To avoid using too many bits in the point structure for specifying point rates, how about having the host give the device an array of up to, say, eight different point rates before starting playback? Then we could devote three bits in dac_point.control to specifying an index into that table. If an application will only ever play back at one rate, then it can just load that array with a single entry and leave the relevant bits in dac_point.control at all zero.

[JohnYayas]

To avoid using too many bits in the point structure for specifying point rates, how about having the host give the device an array of up to, say, eight different point rates before starting playback? Then we could devote three bits in dac_point.control to specifying an index into that table. If an application will only ever play back at one rate, then it can just load that array with a single entry and leave the relevant bits in dac_point.control at all zero.

That wouldn't be helpful in my case since I will use a lot more than 8 point rates and they are computed for each frame based on the current optimizations (which can change as the user tweaks settings during the show). Better to have a single fixed point rate than that scheme.

If it were me I'd just add the notion of a control byte that is used to send commands during streaming. It's pretty simple to implement something like that and it would allow you to send other info to the DAC during streaming besides just point rate.

[DMills]

I like the notion of a command that says something like:

'When executed set the point rate to XXXXX', and a single bit in the per point data structure flags that means execute the pending point rate change.

There could even be a small FIFO so you can queue up a few rate changes and they will fire in sequence as execute bits come down the pipeline.

In fact the notion could trivially be extended to allow any other sync commands we might need to be fired by the same mechanism, have a short fifo of command-value pairs and have them executed only when the execute bit is set in the per point structure.
I cannot think of much else that needs to be sync at the moment (GPIO Possibly?), but the mechanism would not be hard to write.

Regards, Dan.

[mixedgas]

John,

Can I get a beta version from you to test your animation output in a pro, wide throw setting? Since you are doing nearly seemingly everything contrary to carefully thought out industry norms, yet are getting good results, you may have hit on some combination in the right way there, that a lot of good people missed.

Steve

[mixedgas]

Mixedgas wants a knob. Not just any knob, a knob that can rapidly (every 17 or 32 milliseconds ) or so, change frames. Why?, Because when he wants a Dog frame to Sing along with say a DoWop "Be my, Be my, Be my little baby", its a tedious process to hand animate. Some times he'd like to do it real time and follow some one's voice. So maybe a knob input and I mean real KNOB, not mouse, mousepad, or similar Windows EVIL. Ie Can the board can SWIM through about 32 frames in the buffer on call? A zero to 5 volt input with some smoothing. Will accept some clunkiness in the output.

I have this stack of 12 and 16 inch travel medical spec linear potentiometers. They just scream for real time use.
Think Laser Trombone.


One of the coolest things ever was in Branson, Mo. Laser graphics automated along with a Japanese violin player. Had one heck of a control system to allow things like tracking the bow of the violin in laser, and a way for a showop to "Sing" animations to the music, as well as MIDI in. They did not use a clicktrack, the performer set the beat and the show ops followed. The singing bird was just wild. That was 20 years ago, and it should not be this hard.

Yes Team Pangolin, I've asked you for it many, many, times. Starting at LaserFX one year, and many times since.

Yes, I'd like some near real time input functions. I guess the word :live: has been trademarked, so can't call it that. I have a few things like this in LDS with the touchpad, but repeatability is poor.

Expect DSLI Jon to second this within 24 hours, except perhaps the snide shot at the folks in Florida, who I really do respect about 99.6% of the time.

So maybe a bit in the control stream that when set, causes a offset from the A2D to be added to the buffer or sends the A2D data back up to the software?

one knob would be great, a few would be better, and at least 10 bits resolution please, 8 can be tacky looking.

Steve

[masterpj]

Mixedgas wants a knob. Not just any knob, a knob that can rapidly (every 17 or 32 milliseconds ) or so, change frames. Why?, Because when he wants a Dog frame to Sing along with say a DoWop "Be my, Be my, Be my little baby", its a tedious process to hand animate. Some times he'd like to do it real time and follow some one's voice. So maybe a knob input and I mean real KNOB, not mouse, mousepad, or similar Windows EVIL. Ie Can the board can SWIM through about 32 frames in the buffer on call? A zero to 5 volt input with some smoothing. Will accept some clunkiness in the output.

I have this stack of 12 and 16 inch travel medical spec linear potentiometers. They just scream for real time use.
Think Laser Trombone.


One of the coolest things ever was in Branson, Mo. Laser graphics automated along with a Japanese violin player. Had one heck of a control system to allow things like tracking the bow of the violin in laser, and a way for a showop to "Sing" animations to the music, as well as MIDI in. They did not use a clicktrack, the performer set the beat and the show ops followed. The singing bird was just wild. That was 20 years ago, and it should not be this hard.

Yes Team Pangolin, I've asked you for it many, many, times. Starting at LaserFX one year, and many times since.

Yes, I'd like some near real time input functions. I guess the word :live: has been trademarked, so can't call it that. I have a few things like this in LDS with the touchpad, but repeatability is poor.

Expect DSLI Jon to second this within 24 hours, except perhaps the snide shot at the folks in Florida, who I really do respect about 99.6% of the time.

So maybe a bit in the control stream that when set, causes a offset from the A2D to be added to the buffer or sends the A2D data back up to the software?

one knob would be great, a few would be better, and at least 10 bits resolution please, 8 can be tacky looking.

Steve

With the help of lc-max realtime output the dog thing is possible.
Make a 3D model of a dog and make a copy of it and move vertecies so you have the same dog with an mouth open. Use the morpher modifier and assign it to a midi device and then a knob.
Click the motion capture button, either click start to record and save to keyframes or just test to play.

Then move the knob according to the voice.

Or use voice-o-matic (you need to buy that seperate) pre-record the thing you want to sing/ say and make different mouth shapes and add to a morpher modifier, then voice-o-matic automatically generates a lip-sync for you.

I dont have voice-omatic myself, but tried the demo and it is accurate.

[michelrietveld]

first of all, very good idea, second my suggestion, if the laser movement in combination with the emission of laser can be monitord so if a galvo or even two fail the emission is blanked, this to prevent a laser show to be dangerous due to a failling galvo.

Michel

ps, love to betatest, do have spaghetti.

[DMills]

That is what scan fail hardware is for, and IMHO it should NOT be part of the DAC.

Reasoning is as follows: The DAC is a relatively complex software based system which cannot realistically make the sort of SIL 3 or 4 safety/integrity level required for that application. Making it so that any single component failure will result in a safe condition is deeply problematical without adding much additional hardware.

Far better to do a separate card (if anyone can face the liability!), purely in the analogue domain (well, plus a few comparators), as this has a far more restricted state space then the DAC does and thus actually stands a chance of being verifiable.

Finally scan fail hardware should go at the projector, the DAC while it may be located in the projector is often 20+M away on the other end of an ILDA cable (The ILDA standard has no way to sample the galvo positions).

Regards, Dan.

[j4cbo]

Here's a quick little demo video. In this, the DAC is playing the standard ildatest.ild from the microSD card, with playback parameters controlled over the network by an iPad.

http://www.youtube.com/watch?v=Z6Y00xB71Eg

(The projector itself is my ultra-tiny homebrew one - 6" by 8" baseplate, ~750mW. I'll post a thread about it at some point soon.)