Topic: Discussion on blanking timing adjustments and new EzAudDac 1.08 version

[drlava]

Hey guys, this has been brewing for a while, but has only been discussed briefly here until now.  That is, what is the appropriate way to send frames to the DAC driver, and what is the appropriate way for the DAC driver to send these frames on to the hardware in terms of blanking timing.

 I have noticed a trend with Spaghetti in that a lot of the shows that are available expect the lasers to have fast modulation speed in order to be displayed properly.  But, what happens when one tries to play one of these shows with galvo blanking? The frames have heads or tails on the lines unless blanking timing is adjusted by the laser controller, to make the galvo blanking signal slightly lead the xy signals.  What's wrong with that? you say..  well, nothing, until you realize that if you display the ilda test frame with these blanking adjustments it won't look right.  It will only look right with 0 controller blanking adjustment on galvo blanking setup.  So, to display the test frame correctly you need one controller setup, to display the currently available shows correctly you need another setup.  Something's not right.

Similarly, there is an issue with projectors with fast blanking such as our dpss and AOM modulated units.  When one displays the ilda test frame in spaghetti with 0 modulation delay, it doesn't look right, it looks like this:

This can be fixed now by adding in R, G, and B offset delays in the EzAudDac.ini file to simulate the slower galvo blanking. 

This was as close as I could get it, one 48000th of a second sooner blanking looked worse.
However after tuning up the system to make the test frame look as right as possible, when one goes to play a spaghetti show, there are often tails and or heads.


So, what's right?

There are frames available that are meant to be displayed just as the ilda test frame is displayed. 
There are some frames out there that are meant to be displayed with no galvo blanking simulation.
Pangolin loads frames assuming they are tuned to be displayed with galvo blanking.
Spaghetti loads frames assuming they are to be displayed with fast blanking (thus normally the blanking on the ilda test frame doesn't look right.)


Personally I lean toward making the ilda test frame look right with the controller/driver blanking delay if necessary, and then the other content should look right also.  The reason this is important is that if we are going to be sharing frames, this should be hammered out.  Also, it's important because EzAudDac 1.08 now has individual r,g,b,i blanking delay adjustments to make the ilda test frame (and most other frames) look right when it is fed directly to the driver.
 What are your opinions?

[James]

Please explain how you get the ILDA test pattern to clock out properly on a 48KHz, fixed-frequency DAC!

James. 

[Fanny Pack]

Spaghetti doesn't use a constant scan speed when displaying files and it doesn't employ blanking and color shifting in its optimizations.  So, what you are trying to achieve with Spaghetti isn't possible in the manner that you are doing it.

You can force a constant frame rate and you can apply your own blank optimization by making all of your frames have the same number of points and turning off blanking optimizations.  The number of points in your frames will also have to be equal to the max scan rate / frame rate.  For example, if you set the max scan rate to 48000 and frame rate to 30 then each frame should contain 1600 points.  If you do that than I think you will achieve the results you are looking for.

[drlava]

Please explain how you get the ILDA test pattern to clock out properly on a 48KHz, fixed-frequency DAC!

James. 

It's simple, really.  You just slow down the laser modulation control signals to simulate galvo blanking with the laser controller.  Download EzAudDac 1.08 here.  This basically equates to a delay in the modulation signals, determined by the BlankDelay settings in the ini file.  After this is set up, every file that conforms to the ILDA standard with respect to galvo speed and blanking should look right.

Gary, what I am proposing is to take care of this completely in the laser controller (many do this already) and it has nothing to do with Spaghetti except for how a few of the currently available shows are timed with regards to blanking.  The spaghetti example was illustrative of the point I am trying to make..  which is:
when the laser display system (controller, blanking, galvos) is tuned up to display the ILDA test pattern correctly (from any software) then, in my opinion the shows and other frames coming from the software to the DAC should also display properly.

[James]

This could turn out to be a very interesting conversation!

I think we all have our own ideas about how this stuff works out.

I figured out my math with the idea that my DAC would be a fixed frequency; most likely the highest I could get out of a given sound card ~ which seems to be 48KHz, although the echo Layla will do 96KHz.

As far as I can figure, the only way to accurately clock out the ILDA test signal is at precisely integer divisions of the DAC frequency.

LaserBoy corrects for the scanner delay by shifting the color channels back a settable number of samples in time.

I'm quite sure it works. I have been very happy with the way LaserBoy waves look when projected.

I think it is also important to note that the ILDA test pattern is for tuning your scanners! It is meant to be very difficult for your scanners to reproduce! It is probably not the best thing to use for color to scanner time alignment; certainly not in the world of a fixed-frequency DAC.

As far as I know... If you are using scanners to draw and a scanner to blank, then you don't need to make any time difference between the signals. Galvos is galvos! They should all be in about the same time domain.

James. 

[drlava]

Exactly right.  The higher the audio DAC frequency, the finer timing tuning capability you have to make the frame display properly.  While you do this with waves, EzAudDac can do the shifts in real time on incoming data.

 I ran into this with ILD SOS development.  I tuned up a frame so it looked perfect on my system and then sent it to a member with a different software setup.  They loaded it and found the blanking looked all wrong!   What was happening was the software loaded the frame and displayed it in the same way it loaded the ilda test frame and displayed it, except the ilda test frame displayed correctly.  SO the solution was to tune up my laser controller so the ilda test frame looked correct, then load the frame I was working on and tune that till it looked correct.  Then when I sent the frame it finally looked good on the others users system.

It makes perfect sense, really but it was never really spelled out this way.

[drlava]

I think it is also important to note that the ILDA test pattern is for tuning your scanners! It is meant to be very difficult for your scanners to reproduce! It is probably not the best thing to use for color to scanner time alignment; certainly not in the world of a fixed-frequency DAC.

James. 

The ilda test frame is for tuning your scanner and your blanking galvo, so it is also an important reference for color to scanner time alignment.

Yes, galvos are galvos, in basically the same time domain.  This is why we need the controller (and/or something like DZs timing board) to compensate for fast blanking if we use dpss and AOM modulation. 

[Fanny Pack]

The ILDA test pattern is for tuning AND DETUNING your galvos so that they bahave the same as everyone elses.  It's the same as how the DZ color board dumbs down all of the laser modulation to the same level.

If you want 100% accurate frame reproduction from system to system, PROPER use of the ILDA pattern to tune your system is the way to go.  What you end up with is a bunch of frames that are tuned for your system.  When you give them to the next guy, if his scanners are tuned the same as yours, then that means that the frames will also be tuned to his scanners and that they will look right.  But that is only if he displays the frames at the same speed and angle that he used to tune his scanners which in most cases is 30K at 8 degrees.  Scanners are not linear devices so if you both tune your scanners to 30K@8 but you create your frames at 30K@ 20 that will not mean they will look good at 30K at 20 on the next guys system.   In fact, there is no guarantee that they will look good on his systems at any combination.  It only works if you design them at 30K @8 and he displays them at 30k@8.

People that run their scanners in small rooms (ie most hobbyists) will want a scan angle greater than 8 degrees or else their image is tiny.  So, they jack up their angle and run their scanners in a detuned state.    Also, some of these people may only have 20K scanners (or some other speed) which make it impossible for their systems to ever be tuned the same as a 30K set.  These reasons are why I designed Spaghetti's optmizer as it is.   It will compensate for the wide angles and slow speeds as best as it can and give decent results on cheap scanners.  Spaghetti is made for the low man.

[drlava]

Gary, I think you might be missing my point here..  This isn't about scanner tuning really it's about standardization.  What I am saying is that there are two standards I see emerging in 'common man' work: 1) ilda frames (and shows) that are blanked assuming dpss blanking.  2)  ilda frames and shows that are blanked assuming galvo blanking (like the ilda test frame). 

We should either 1) standardize on the traditional method of releasing frames blanked assuming galvo blanking, with the ilda test frame as the standard, or 2) throw the ilda test frame out the window except for x/y tuning and standardize on releasing frames that assume dpss/AOM blanking (this requires that a tuning/blanking standard be developed for this mode).

[Fanny Pack]

I'd prefer them to be released with computer screen blanking so that they look correct on a computer screen.  You can then apply whatever optimizations to them that you want to make them look good on your scanners.

[James]

I think Gary is (sort-of) right on this one.

A set of frames is just that. It's a set of frames. It does imply some characteristics about how it gets optimized for scanning; but that implication is only a matter of the total number of points it has.

Obviously, without omitting points, it will take a certain amount of time just to get through all of the points present at some rate of points-per-second.

Other than that, one of the more complex tasks I had to accomplish with my code was to figure out how to make a set of frames look good, at or about a specified frame rate, on any given projector.

That is why there are so many parameters for optimization AND it is why those parameters are stored in the resulting wave; so that the optimization can be understood at a later date, undone and redone for a different system.

I think you are looking for The Golden Fleece!

There is no commonality between all of the laser projectors that are out there.

That is just another reason why the ILDA file format is so important!

It is the art without any concept of time.

James. 

PS. Sorry Gary. I just can't aggree with you completely. What fun would that be? 

[drlava]

Ok, but you are basically agreeing that they should be in galvo blanking format, which I also agree with.  And we know that these can't be sent right to the DAC (if it doesn't have point shifting) on a dpss system and expect them to look right.  Gary adds lit and or blanked points at the transitions to compensate.  What I'm suggesting is that is won't be necessary to add so many points when we let the controller (EzAudDac or RIYA in this case) do its thing with blanking shifting.

[James]

ILDA is ILDA!

There are no "modes".

ILDA is not intended to be shoved into a projector as-is.

The idea of optimizing vector art and saving that as ILDA so that it can be fed into a program that has poor or no optimization capabilities of its own is WEAK.

If you're using a program that is written to display ILDA frames and it has no means of optimizing them, GET ANOTHER PROGRAM!

I can think of at least one good one that is free! 

James. 

PS. The stream of data that flows from a laser signal generating application to the DAC (of any kind) is not ILDA!

It need not, should not, and can not be standardized!

[drlava]

There are many frames out there, the best hand-done and most popular frames ARE pre optimized, and if you try to run those through an optimizer again, generally you get crap!  The only thing that needs to be done to these frames for proper display is the blanking shift!  no more points added!  This is not a weak idea dude, it's been around for a long time and has been used by the best with success.

[James]

That is a good and valid point.

It's also why you can turn off the optimizations in LaserBoy.

There are some GREAT examples of ILDA frames that are point ready.

Dean's program produces waves, that, when converted point-for-point into ILDA are point ready AND LaserBoy would wreck them if they were optimized before they were converted back to wave.

Similarly, there are some unbelievable frames out there that were hand drawn, a point at a time, to take full advantage of the inertia of the galvos. The frames look really weird on a computer screen. But that's not what the artist was looking at when the frame was drawn!

James.