Lissajou Art

[Perfect Human Interface]

There are always substantially more views and downloads on this forum than there are comments or commenters. I dunno who these people are, but that's always been my observation.

Anyways, as I just plainly mentioned, I think creating a visualizer for audio could be a lot of fun, but I think Flowstone is too slow to create sophisticated graphic effects. At least with the built-in components.

[tulamide]

Anyways, as I just plainly mentioned, I think creating a visualizer for audio could be a lot of fun, but I think Flowstone is too slow to create sophisticated graphic effects. At least with the built-in components.

That's not quite true. Of course, you can't do something like "Dancer". It runs at 60fps with vertical sync, does a complete physics simulation of 15 joined body parts via Box2D, has a particle system (you can see it in the background) and pixel shaders (for example Gaussian Blur on the particles). All of the visuals are done by the graphics card, so that the cpu is pretty much bored with "only" calculating physics, particle positions and the audio events.

That's the trick in multi-tasking. The more time-consuming part is almost always the graphics. If you can take that away, you don't just have double the power, but even more (almost triple the power). That's because it can compute, while the graphics card is busy drawing, so that the next frame's calculations are already done, when the graphics card is ready to draw the new frame.

There are possibilities to access OpenGL via Ruby (which would allow for above mentioned multi-tasking). But with the built-in components, we can still do a lot, given that
1) we can live with unsynced (read unstable) 25 FPS
2) we can relinquish pixel effects, which are very time-consuming when not run as a shader on a graphics card
3) we use Ruby

I already played quite a lot with my spline class, driven by an 8-band bandpass, and it works quite well. But it's just a quick playing with the possibilities, nothing fancy yet.

[Perfect Human Interface]

I just don't personally see the point in putting time and effort into something that's purely meant to be pretty visuals when we can't even match things done 10 years ago on a technical level. If it sounds like a fun project to you then I could understand that, but I'm much more interested in the end result than the work involved getting there.

1) we can live with unsynced (read unstable) 25 FPS

It's really more like 15 fps, and that of course depends on hardware and how fast Ruby can draw stuff, which seems to me pretty darn not-fast. I've often had visual components crash schematics when I've tried to drag the view/draw window too large. And I'm running a 4.5 Ghz i7 so I'm not wanting for processing power.

[tulamide]

I just don't personally see the point in putting time and effort into something that's purely meant to be pretty visuals when we can't even match things done 10 years ago on a technical level. If it sounds like a fun project to you then I could understand that, but I'm much more interested in the end result than the work involved getting there.

1) we can live with unsynced (read unstable) 25 FPS

It's really more like 15 fps, and that of course depends on hardware and how fast Ruby can draw stuff, which seems to me pretty darn not-fast. I've often had visual components crash schematics when I've tried to drag the view/draw window too large. And I'm running a 4.5 Ghz i7 so I'm not wanting for processing power.

I'm not quite sure, what you are trying to say. I didn't try to convince you doing visuals, I just said, that it is possible. Also, whatever negative you might have found, the lissajou art is affected just the same. Still, I didn't hear you say the same for lissajous.
Also, you are wrong in your Ruby assumptions. Ruby runs at 100 Hz if not sync'd to ASIO (else it even runs at audio-frame speed), and it is a lot more stable than the windows timer the primitives use. So I guess your schematics contain "brakes" somewhere. But of course, FullHD wouldn't be possible (I even doubt HD)
The size of the current lissajou display however is possible.

[Perfect Human Interface]

I was just responding to your comment:

so I guess, there's no interest in audio visualization via Flowstone.

I am interested in it, I just don't think Flowstone is up to the task. Lissajou is something else because it's just drawing a line on an X-Y coordinate; it's cool because it's a novelty how it's generated, not because of what is generated in and of itself. We had wireframe vector graphics in the 1980's.

[tulamide]

I was just responding to your comment:

so I guess, there's no interest in audio visualization via Flowstone.

I am interested in it, I just don't think Flowstone is up to the task.

Yes. I know. But that's my point. I just said, it is possible (and provided explanations and examples). Still it seems, you're trying to convince me it won't. That's not neccessary. We just have two different opinions.

Lissajou is something else because it's just drawing a line on an X-Y coordinate; it's cool because it's a novelty how it's generated, not because of what is generated in and of itself. We had wireframe vector graphics in the 1980's.

Actually in the 70s already (see example link). But that also wasn't my point. Maybe there's a misunderstanding in how graphics work?
The display you currently use for lissajous is drawing a rectangle of the size of the display 100 times per second (Tick100). Also, it's not drawing a line, it's drawing many lines connected via points (1023 lines in "Lissajou display for VST effect_PHI Edit.fsm" to be precise), also 100 times per second, The phosphors module even creates 100 bitmaps of the size of the display per second. I couldn't find any area redraw, it is always redrawing the whole display. That is actually quite a lot, because the display is large. I would say that Flowstone does a pretty good job to actually manage this (especially the phosphors module). It's more that we often don't optimize things, that makes it unbearable.

[Spogg]

Please keep this argument going! I'm learning a lot from it. Stuff I'm imagining for the future may be pretty demanding of FS and any optimisation of the display (or anything really) by the Eagle-Eyed Tulamide might well help the cause of Lissajou Art.
C'mon Tom, you know you want to...

[Perfect Human Interface]

Please keep this argument going! I'm learning a lot from it.

Ok

I was just responding to your comment:

so I guess, there's no interest in audio visualization via Flowstone.

I am interested in it, I just don't think Flowstone is up to the task.

Yes. I know. But that's my point. I just said, it is possible (and provided explanations and examples). Still it seems, you're trying to convince me it won't. That's not neccessary. We just have two different opinions.

I'm not saying that it's impossible, more than the performance isn't there. I would be happy to be wrong about that. But I've never seen anything that demonstrates otherwise. Simple drawing at limited framerates seems possible. If I personally were to attempt to create an "audio visualizer" I would want to make something that looks very fancy.

There's also the simple fact that advanced graphics features don't exist within Flowstone and would have to be written from scratch or imported somehow. That is beyond me.

Lissajou is something else because it's just drawing a line on an X-Y coordinate; it's cool because it's a novelty how it's generated, not because of what is generated in and of itself. We had wireframe vector graphics in the 1980's.

Actually in the 70s already (see example link). But that also wasn't my point. Maybe there's a misunderstanding in how graphics work?
The display you currently use for lissajous is drawing a rectangle of the size of the display 100 times per second (Tick100). Also, it's not drawing a line, it's drawing many lines connected via points (1023 lines in "Lissajou display for VST effect_PHI Edit.fsm" to be precise), also 100 times per second, The phosphors module even creates 100 bitmaps of the size of the display per second. I couldn't find any area redraw, it is always redrawing the whole display. That is actually quite a lot, because the display is large. I would say that Flowstone does a pretty good job to actually manage this (especially the phosphors module). It's more that we often don't optimize things, that makes it unbearable.

My own testing has shown the tick100 prims actually put out around 60 triggers/sec on average (unstable of course). And the lissajou display I modified with the "phosphors" is not drawing that fast. That's why I subsequently removed that module, because to me it looked better to have a faster redraw. I don't know that there is any way to measure redraw rate in Flowstone, but it was noticeably improved without that. Again, this is with a fast computer.

[tulamide]

I don't know that there is any way to measure redraw rate in Flowstone, but it was noticeably improved without that. Again, this is with a fast computer.

It would be quite difficult to do it for green (if you'd use Ruby it could adulterate the results), but for Ruby I can offer you this measurement.

Make sure your monitor is set to larger than 720p (1280x720), unrar and run the .exe, wait for at least 15 seconds, then it should be quite accurate. For me this results in roughly 64 fps - and I have a slow, 7 year old pc.

I've also attached the schematic, but start with the executable, because it doesn't get influenced by all the editing functions of Flowstone, which adulterate the results.

So that's at HD, the smaller size of the lissajou display should be even faster (and therefore offer more headroom for advanced graphics). It could go all the way down to 25 fps before it's not usable anymore.

[tulamide]

Here is a prototype of a lissajou display, working in frame sync via Ruby.

CAUTION: You can start it by activating the sound out driver, but if you afterwards try to close the driver, FS will crash to desktop (at least on my pc). You can, however, just exit FS instead, and it will not crash then. I suspect it may be somehow related to the 1-frame-delay, introduced with mono to frame?

Maybe some dsp experts could help with this issue?