The LaserBoy Thread

It's interesting how we all have substantial knowledge and experience in this space but it is so very different.

Another wrinkle in the process of exporting anything that might be found in an ilda file is the time alignment between the scanners and the color modulation signals. Color is instantaneous but scanners take time to arrive at the positions indicated in the x y signals. This is managed in a wav by shifting samples, creating a delay on the color signals. In my wav file extensions, there is an array of integers that contains the number of samples shifted in each channel, so when the wav is read back into the app, the colors and x y (possibly z) can be properly realigned. There is nothing like this in the ilda file format because there is no notion of time, or at least there is no concept of dac close frequency.

So, if you ever have the inclination to record your signal set as multichannel wav and you'd like to convert that to ilda, you can get ilda frames that accurately represent what the wav looks like when projected. It doesn't need to have the special formatting extensions to be able to open it and realign it.


.

i would not embed color timing information into an ilda file as different projectors have different modulation characteristics. leave that to the ilda player to manage instead of baking it into the file.

Quote:

---

Originally Posted by james

It's interesting how we all have substantial knowledge and experience in this space but it is so very different.

Another wrinkle in the process of exporting anything that might be found in an ilda file is the time alignment between the scanners and the color modulation signals. Color is instantaneous but scanners take time to arrive at the positions indicated in the x y signals. This is managed in a wav by shifting samples, creating a delay on the color signals. In my wav file extensions, there is an array of integers that contains the number of samples shifted in each channel, so when the wav is read back into the app, the colors and x y (possibly z) can be properly realigned. There is nothing like this in the ilda file format because there is no notion of time, or at least there is no concept of dac close frequency.

So, if you ever have the inclination to record your signal set as multichannel wav and you'd like to convert that to ilda, you can get ilda frames that accurately represent what the wav looks like when projected. It doesn't need to have the special formatting extensions to be able to open it and realign it.


.

---

Quote:

---

Originally Posted by swamidog

i would not embed color timing information into an ilda file as different projectors have different modulation characteristics. leave that to the ilda player to manage instead of baking it into the file.

---

Yes. Absolutely. There is no defined way to do that in an ilda file and that's just another reason to assume that an ilda file requires some processing before it is streamed to a dac.

What I was going on about is the situation where someone is using some kind of signal generators akin to a modular synth or digital representation directly into a laser projector. If you would record that as x y r g b and open it into a vector art environment to save it as ilda, it would not look right unless the color signals were realigned in time with the scanners.

Quote:

---

Originally Posted by james

What I was going on about is the situation where someone is using some kind of signal generators akin to a modular synth or digital representation directly into a laser projector. If you would record that as x y r g b and open it into a vector art environment to save it as ilda, it would not look right unless the color signals were realigned in time with the scanners.

---

That would all depend on the method used for recording the XY/RGB signals.

Quote:

---

Originally Posted by lasermaster1977

That would all depend on the method used for recording the XY/RGB signals.

---

Well, if you assume that all 5 signals are being recorded (digitally) all together simultaneously, then you would have the issue of time misalignment between the scanners and the colors. It would play back into the projector just fine. But reading it into a vector display app to convert it to ilda would require realignment.

It certainly sounds like it would work.

With pure abstract stuff color alignment isn't such a visible issue. It is what it is. But with graphics stuff like text or images, it's an absolute must. Otherwise the lasers are going on and off ahead of where the scanners are.

In a 48KHz wav, the colors are shifted 5 samples back in time. It is of course dependant on the sample rate.

I love chatting about this stuff in a calm, positive environment.

If you look at the pictures I took way back in 2005 when I had my little 30mW gas rig with a 4 channel pcaom you can see where I was experimenting with scanner to color time alignment. It's possible to set the individual channels to whatever sample shift you want, behind or ahead of the scanners. The star explosion pictures show this.

https://laserboy.org


.

Quote:

---

Originally Posted by james

I've answered more than one.

Like I said there is a huge gap in the idea of what an ilda file should be.

The most likely answer is that the format was just for the purpose of getting vector art out of one proprietary app and into another; each having its own way of utilizing that generic information. And that capability was entirely voluntary by the app developer. I don't think it was ever intended to be a feature rich format for direct unprocessed display.

I think you might have some idea about the lack of cooperative attitude with regard to this particular file format.


.

---

You're overanalyzing! *retardo


I just asked for a simple wraparound option when optimizing an individual ild frame (like a logo) for looped playback.
If you don't want to code in the extra option in LaserBoy then just say so, and I'm OK with that- just don't dismiss
the idea of an optimized wraparound frame because it doesn't fit some preconceived notion of what an ild frame should
or shouldn't be. :rolleyes:

Attached is an excellent example from the PL-FTP of a wraparound frame that doesn't start/end at the origin.

What? Me overanalyze something? Well I never!

I suppose my tendency as a developer is to find a solution that works for all kinds of situations, even those I can't imagine on my own.

I'll come up with something. The trick isn't about creating the new feature. It's always a challenge to figure out where to put it in the menu system!

.