Topic: HUGE !!!

[James]

LaserBoy just "floated" silently through a plain ASCII text substitution of the word 'float' for the word 'double'.

Code: [Select]

OOOOOOOOOOOOOOOOOOOOOOOOOOOO
MMMMMMMMMMMMMMMMMMMMMMMMMMMM
GGGGGGGGGGGGGGGGGGGGGGGGGGGG
!!!!!!!!!!!!!!!!!!!!!!!!!!!!

That means that all of the real number calculations in LaserBoy just went from 32-bit to 64-bit in one maneuver, with no cost!

I am simply blown away............ This is so cool. I can not convey how awesome this is!

WEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEE !!!!!!!!!!!!!


James. 

[BlinkenLights]

real numbers? Nice...

They are still hobby numbers right? or are they now professional numbers?

[James]

I've just upgraded to semi-professional numbers.

The numbers and math I use now are made in some factory in China as the top-of-the-line knock-offs, so you can hardly tell the difference.

Some day, I'm going to order a bunch of German made numbers!

But then I'll have to switch over to using industrial electrons too!

James. 

[James]

In a conversation with Dean last night, I realized I'm going to have to regenerate the LaserBoy wave header additions.

This is a result of now having to store 64-bit real numbers instead of 32-bit.

No biggy. The LaserBoy wave header addition has a version number and LaserBoy knows how to read anything it has ever written!

I will be releasing the new version with 64-bit (double) real number math pretty soon!

If all goes well, you won't notice a thing! It will blow your mind!

CORRECTION:

Upon examining the code for said changes, I realized that it's OK to store a few factors as single presision floats as long as all of the math is done with doubles. So, I'm not going to need to store doubles in the wave header.

James. 

[meandean]

  Hey James!

  I take it you didn't read the Velocity Limit Testing section of LW's Tour doc...

   "Galvos can only travel so fast, this test determines where the limits are. You do not need to generate 6ch, just use the built-in stereo player and set your color modulator (if you have one) for pass-through. Make sure Use Default Settings is not selected and turn off any effects including Velocity Limit Factor. Set the Duration to 3 sec, and the Sample Rate to 48000, dbl-click plot 1001 and click the Play button on the LW Control Panel; you should see a full-size circle drawn at a rate equal to the Base Frequency (which should be 100Hz). Selecting Continuous Playback makes the test a little easier. Since the signal is full-scale, this is a good way to set your galvo gain to get the desired projection size and aspect. Once the gain is set, try raising the Base Frequency a little at a time and re-generating the plot. Eventually, the circle will become distorted as the frequency gets higher- once this happens, back the frequency down just to the point where the plot is not distorted. Turn on the Velocity Limit Factor and re-generate; start lowering the Velocity Limiting Factor a little at a time to get to the point where the circle starts to distort, this will be your optimum setting for the specified Sample Rate. It is better to restrict velocity in software, as excessive velocity in a signal can build up heat in galvos."


  Once the velocity limiting factor is found, multiply it by 64k to get a max 'integer distance' per sample.

[James]

Get in your car and drive 24 miles Southeast.

We have a lot of work to do!

James. 

[James]

Here it is !!!!!

64 fabulous bits of real number calculations !!!

Wooooooooooooooooooooo Hoooooooooooooooooooo !!! 

http://www.akrobiz.com/laserboy/code/LaserBoy_04_08_2009.zip

So far I can't see any difference!

Isn't that awesome!

James. 

PS. Don't worry there are plenty more bugs!

There will be more and more and more releases of LaserBoy! 

As always, please report any unusual behaviour....

No. Forget that.

Just report bugs, please!

[meandean]

 I just noticed that if you flip polarity on an individual wave channel in LB and load it back up, the display is not automatically corrected (as the global polarity does).

[James]

Huh?

That works OK for me!

Do you see the block that describes the contents of each channel?

ch: sig : contents : LSB subcode : offset : res

Look in the sig column.

James. 

[BlinkenLights]

it does not visually flip because it knows its inverted (in the header) so it displays it correct

dont know if thats true, i just made that up...

[James]

I don't get it.

All systems are go here.

As far as I can tell, it does exactly what it is supposed to do!

Maybe you have a weird case. What are you working on?

James. 

[BlinkenLights]

maybe "what its supose to do" and "what he expects it to do' are different

[meandean]

  Here's what I did... I opened LB 4/8 (with default settings) and rendered in.ild to wave, next I used option 8 from the wave utilities menu to invert X only; when I loaded the wave back up in LB, I got a mirror image on the screen. Had similar results with color channels, but if you use the global invert by itself everthing loads OK automatically. LW behaves the same way with LB material because I haven't coded in an automatic read for LB's recent invidual polarity settings yet as I did earlier for the global invert.

[James]

Well, it kinda' makes sense that way. Don't you think?

If the whole wave is inverted, LaserBoy should load it in its correct orientation. But if an individual channel is inverted, there must be a reason for that apart from the global polarity, so. LaserBoy respects the relationship that exists between that channel and it's relationship to the global polarity setting.

BTW I'm actually working on that part of the code right now (sort-of).

I'm rewriting the part that imports wave data from non-framed wave sources. It will be able to aply the system settings for wave channel offsets to the imported data in order to realign the channels in time. The non-formatted wave screen display already does this.

I'm reworking a lot of stuff about wave import, so I can have better tools for decoding ADAT and other recorded archival laser signal information.

James. 

[meandean]

  Well, if that's the way you want it to behave, it's easier for me, as I won't need to make any changes to LW to accomodate (but I should add provision in LW for separate polarity for X & Y). I'd still like to get the transfer of floating point numbers between our apps figured out...