CYGN-B

[laserist]

Thanks, I've been thinking about how to build a better performance console for a long time. My previous post is the image processing section. There are two other sections, image generation and control/automation. Any number of things can go into image generation, but there are rules. Everything has to be either digitally or voltage controlled. And all of the controls run through the control/automation section. This allows an iterative approach to developing a performance and allows the performer to override things in real time. Or the data can be edited later. I've thought about trying to totally lasso lumia into this paradigm, but since you can't instantly jump to the other side of the disk or what ever lumia doesn't completely fit. So I'd make an exception for some aspects of lumia, but the housekeeping would still go through the control/automation section. Obviously there are lots of ways to implement the override function. I doubt it would be practical or desirable to have the override on the individual pot or switch level. Choosing the level of complexity of the override capability is a huge multiplier of the complexity of the system as a whole.

[Greg]

This allows an iterative approach to developing a performance and allows the performer to override things in real time. Or the data can be edited later. I've thought about trying to totally lasso lumia into this paradigm, but since you can't instantly jump to the other side of the disk or what ever lumia doesn't completely fit.

I'd like to develop a performance using an iterate and override approach on a capable console, for sure. Regarding the lumia, I read somewhere I think from Pangolin about a prototype rotational galvo for just such a purpose that performs up to some crazy speed and accuracy.

On such a console I would like to experiment with such a controller as a cylindrical guitar slide lodged in a lump of silly putty like material, and thus stuck onto a base plate that would have it's X, Y, Z, and Z rotation pressure vectors transduced. Given the feel of trying to move around a guitar slide stuck to a base with silly putty, I expect that a ponderous graceful vector describing the 3D motion path of a point could be achieved.

I've found some sections in the Laserium79 351 data in which there is much activity in the SPIRAL RATE, SYM, and SWEEP bytes. The SPIRAL RESET EN. bit seems to be being used as just that, an enable. It comes on for many seconds, and then turns off. So I haven't seen it used as a BAM ramp reset lick generator, though I haven't looked through everything yet. It is coming on along with an adjacent bit SHUTTER ENABLE which I don't know what that is or does.

I'm currently working to expand the visualizer software to give a better idea of what this spiral board activity is doing. I expect it is doing something pretty darn interesting and clever.

lasermaster1977: I hope nothing I said was viewed as a sleight. I was just trying to riff on the "dog" thing. Please let us know if you are able to get anything useful from the c64 Fast Assembler source file I sent.

[laserist]

Spiral reset could be used to sync the spiral to a beat, but it required the laserist in the loop since there was a wide range of fine adjustment for the spiral ramp. With the ability to do set ramps of the individual gains on the master encoder spiral reset became less of a thing.

Shutter is just that, a ledex solenoid with an arm that blocked the raw beam. I suspect most laserists just left the override active since the master fader was more nuanced and not noisy.

[lasermaster1977]

lasermaster1977: I hope nothing I said was viewed as a sleight. I was just trying to riff on the "dog" thing. Please let us know if you are able to get anything useful from the c64 Fast Assembler source file I sent.

No sleight taken, but I believe I did post that I have no way of opening and viewing the Fast Assembler "source code" you sent me. All I could do is view it as a binary data. Please reread my post for details.

[Greg]

lasermaster1977 made an observation regarding the way the 555 is used on the DOGN board. When I looked through what Forrest M. Mimms III says on the 555, I found no configuration in which the IC is configured without pin 1 grounded and 8 and 4 hitting the positive supply. I have yet only a minimal understanding of how the configuration of the 555 in general results in it's various operations.


Attached shows the 555 on both the DOGN and the CYGN-B. Interestingly similar. Other attached shows relevant waveforms.


Update on visualizing the SPGN 351 mystery:


The ideal specimen of 351 data singing to the Spiral Generator board has been identified. It is the last minute of track 5 of Laserium79 which happens to be Just What I Needed - The Cars. These frames of 351 data are ideal because only and all of the bits of interest are active during this coda. Notably, the SPIRAL RESET EN. bit is functioning as described by Brian, and is clearly pulsing in a way related to the beat of the music. The offsets and enables simply permit the images to appear full gain and centered until the end of the song, at which there is a 2 second size decrease to zero.


The 351 data visualizer software is being developed to give us a view, and we expect to find some brilliant choreographer's laser animation from 1979.

[lasermaster1977]

lasermaster1977 made an observation regarding the way the 555 is used on the DOGN board.

Aaah, interesting comparison.

The main thing I pointed out was that for pins 4 and 8 to be at ground that meant the triggering voltages on the 555's internal comparator inputs, 2 and 6, must be negative. On the CYGN-B 555 example you provided they indeed are. On the DOGN's edge connector X and 18 pin inputs, it appears they are inputs to the MC1458 comparator opamp. As I do not know the polarity or nature of these inputs, but if they are negative the comparator output would drive pins 6 and 2 negative with respect to ground.

Knowing the nature of pins X and 18 signal inputs are key to understanding how the 555 circuit functions.

Note: edit clarified one comparator reference was to the 555's internal comparators.

[Greg]

Update with something new and interesting to look at:

The Spiral board based Just What I Needed number is proving a tough nut to crack. I have a simulation of the ramp generator and it's analog and digital parameters working, but have more work to do on the visualization side before I can look for clear evidence that the intended effect is being achieved.

What has been developed is place holder images which indicate the A / B bus content as determined by the 351 data.

Fed to this visualizer update is The Wait by The Pretenders, from Laserock2. While watching, please keep in mind that, if memory serves, this was a joystick heavy number, and the relevant data bits support this, see attached. I would like to pin down the correct functions that the joysticks played in this and other numbers.

Please see the video here:
https://youtu.be/HiQN7x5q6_g

I'm guessing / remembering that the right hand stick was always active, controlled by a gain dial and a quad / opposition switch. And the left hand stick did nothing unless the data set the correct rotation signal select bits. Was there a case in which offset and rotation signals came from the same stick? The console I encountered had no controls on the joystick side pods, other than the sticks themselves.

[kecked]

How is that 555 running off a -15v supply? Never seen that. I guess so long as the Gnd is more neagtive it should be ok.

[ronhip]

Greg,

Move and rotate could be assigned to either joystick, either separately (move right joystick/rotate left joystick - or the reverse) or you could assign movement AND rotation to the same joystick. In addition, there was a switch so that all four colors would be moved in the exact same direction (grouped) so they were always on top of each other. One more joystick switch we had, made all four colors move in the same direction (all four colors would rotate clockwise if you moved the joystick clockwise, but separated by 90 degrees), or two of the colors would be reversed and move opposite the other two colors. I don't know if my description makes sense because I've internalized it after 20 years of using it.

So, 4 joystick switches (found on the bottom of the console):

1) Move - left joystick or right joystick
2) Rotate - left joystick or right joystick
3) Group - move all four colors in the same direction and distance taking signals from the "move" joystick
4) Follow or Oppose - make the directions the colors move the same direction, or 2 colors opposite the other 2 colors, for example yellow/green move clockwise, and red/blue would move counter-clockwise.

OK, I'm done confusing you for the evening.

Ron

Update with something new and interesting to look at:

The Spiral board based Just What I Needed number is proving a tough nut to crack. I have a simulation of the ramp generator and it's analog and digital parameters working, but have more work to do on the visualization side before I can look for clear evidence that the intended effect is being achieved.

What has been developed is place holder images which indicate the A / B bus content as determined by the 351 data.

Fed to this visualizer update is The Wait by The Pretenders, from Laserock2. While watching, please keep in mind that, if memory serves, this was a joystick heavy number, and the relevant data bits support this, see attached. I would like to pin down the correct functions that the joysticks played in this and other numbers.

Please see the video here:
https://youtu.be/HiQN7x5q6_g

I'm guessing / remembering that the right hand stick was always active, controlled by a gain dial and a quad / opposition switch. And the left hand stick did nothing unless the data set the correct rotation signal select bits. Was there a case in which offset and rotation signals came from the same stick? The console I encountered had no controls on the joystick side pods, other than the sticks themselves.

[Greg]

Thank you Ron, for this and your many contributions. With out the exact audio which you cared to archive, these classic audio / laser synchronization licks being visualized would be much less certain.

Beginning with the following snips of previous comments:

a 3U euro card format that did:Multiplex 16 x/y image selection
Master x&y gain
Individual x&y gain
Variable rotation
Fixed rotation
Audio mod multipliers with some switching
Spiral multipliers with some switching
A place to insert offset
A place to insert spiral sweep
A place to insert a different kind of spiral sweep


It would be one channel per card.


the image processing section. There are two other sections, image generation and control/automation. Any number of things can go into image generation, but there are rules. Everything has to be either digitally or voltage controlled. And all of the controls run through the control/automation section. This allows an iterative approach to developing a performance and allows the performer to override things in real time. Or the data can be edited later. I've thought about trying to totally lasso lumia into this paradigm, but since you can't instantly jump to the other side of the disk or what ever lumia doesn't completely fit. So I'd make an exception for some aspects of lumia, but the housekeeping would still go through the control/automation section. Obviously there are lots of ways to implement the override function. I doubt it would be practical or desirable to have the override on the individual pot or switch level. Choosing the level of complexity of the override capability is a huge multiplier of the complexity of the system as a whole.

I am interested in pinning down with as much certainty as possible what exactly this describes. I can't offer much to a project like this except organizing information and writing software. Even if no more than a discussion of ideals, these could be an interesting and useful set of ideals to consider.

Attached graphic illustrates my current understanding of the overview being described.

Thoughts / questions:
1. Does "Multiplex 16 x/y image selection" mean 32 pins for 16 differential inputs, or does it mean stack inputs through serialization or something?

2. Is one requirement to offer an all analog signal path from the image generators through processing to the output?

3. Are color signals brought through the image processing board, or in other words, is the output of each processing board similar or equivalent to an ILDA out?