DSP Robotics Support

Hey tulamide!

That's a great display and you made it with such a small amount of code. That is so clever (as always!). Are you going to develop it further?

To test it I put the ogg file through it and I found I had to invert the phase of the Y channel (as per the file below).
It looked great.

My FS only crashed when I deleted the output sound driver, not when I switched it off by de-selecting the Primary driver. I used ASIO (Creative ASIO) and it was good and stable on my PC.

On the initial version you uploaded I did hear a ticking sound while the display was running, like the audio was being interrupted maybe.

I must learn Ruby.
I must learn Ruby
I must l...

Spogg,

I plan to develop it further. But I hoped to have some one solving the crash issue first, that's why I posted it that early. It isn't very advanced. For example, the phase invert won't be needed when I'm done with the display. It is because currently -1 is interpreted as Top and +1 as Bottom (I'm used to it, from graphics). But it seems, music/audio needs to be interpreted the other way 'round. Also, it currently draws everything curved. You will have a more precise output, if you change


into


(Exactly as written above)


There are quite some possibilities with Ruby that would be much harder to realize in green. Also, this is not losing any sample! It runs at audio rate, frame based. Really each single bit of audio is captured (as opposed to the Tick25 or Tick100) and drawn. So yes, I will work on it, but only after the color mixer (which I renamed to "Advanced Color Management" because of its many additional features) is done.

Hey Tulamide, I tried out the FPS thinger, and I'll just have to take your word that it's working correctly as I can't tell anything looking at a bunch of flashing colors like that. It's cool that it seems to be possible though. I did also get 64 fps with the .exe, so that seems to suggest that the hardware on board isn't limiting it. Is vsync possible, by the way?

That's an interesting lissajou display too. I don't think it's actually an improvement as you think, as the green version also gets every sample with the Graph prim, as long as the number of samples per "snapshot" is equal or greater than the sample rate divided by the trigger rate. And in fact, I think your display isn't drawing enough samples, as it looks very flickery with the "oscilloscope art" audio. It does the same with the Graph prim if you set the number of samples too low.

I also notice that it seems to "overdraw" some lines a good bit (for example, when the cube is drawn towards the beginning). The same thing happens with the PALines prim, for reasons I don't understand, when the pen size is set higher than 0.1. So I tried setting the pen size in yours to 0.1 and it did correct the issue. It would be nice to be able to draw it a bit thicker but I don't know why it does that.

But, since it's in Ruby like you say there should be more flexibility and possibilities.

By the way, it looks a lot better to me with curved drawing in some cases.

Perfect Human Interface wrote:Hey Tulamide, I tried out the FPS thinger, and I'll just have to take your word that it's working correctly as I can't tell anything looking at a bunch of flashing colors like that. It's cool that it seems to be possible though. I did also get 64 fps with the .exe, so that seems to suggest that the hardware on board isn't limiting it. Is vsync possible, by the way?

That's an interesting lissajou display too. I don't think it's actually an improvement as you think, as the green version also gets every sample with the Graph prim, as long as the number of samples per "snapshot" is equal or greater than the sample rate divided by the trigger rate. And in fact, I think your display isn't drawing enough samples, as it looks very flickery with the "oscilloscope art" audio. It does the same with the Graph prim if you set the number of samples too low.

I also notice that it seems to "overdraw" some lines a good bit (for example, when the cube is drawn towards the beginning). The same thing happens with the PALines prim, for reasons I don't understand, when the pen size is set higher than 0.1. So I tried setting the pen size in yours to 0.1 and it did correct the issue. It would be nice to be able to draw it a bit thicker but I don't know why it does that.

But, since it's in Ruby like you say there should be more flexibility and possibilities.

By the way, it looks a lot better to me with curved drawing in some cases.

Thanks once more for your input, PHI

Yes, the color flashing was just to visually signalize that redrawing is going on. The only important part is the displayed FPS. I probably should have given an epilepsy warning though
Synchronizing is not possible (unless using OpenGL), that's why you see that ugly banding from the color flashes.

Please keep in mind, that the lissajou display was just a (very) quick proof of concept. It wasn't optimized at all. But some of the things you mention are not as you describe them. So let me clear things up, where possible.

1)The display is drawing exactly what is coming from the monos. No more, no less. Maybe I should have been more precise in describing it. The advantage of frames over green is that the former is sync'd to audio.
When audio is given to the audio card/chip, it is done so in blocks of data, called audio frames. A frame contains all channels an audio card/chip can handle, and the length of a frame depends on the used driver and the system's speed. When using ASIO or ASIO4ALL, a user also has the option to define a frame size via ASIO control panel.
Whatever of the above, FS provides a way to slice the mono streams in portions of exactly that frame size (since the technique behind this is a double buffer system, the last but 1 frame is used, which introduces a delay of the frame length, but let's keep that aside). What you get is exactly what is about to be played by the audio card/chip. No matter how fast or slow your computer, or how fast or slow you draw. A frame is sent just before needed by the audio system.
The green tick25 and tick100 however have nothing to do with the audio stream. They are very inaccurate windows timer measures. You can even provoke a total halt of the ticker prims, not sending a trigger at all. So, they are unreliable, imprecise and not audio related. To compensate for that, you buffer a larger amount of data than would be needed (just as you described), forcing the drawing prims to draw data that was already drawn. If you want to learn more about mono to frame, have a look at the manual's Ruby chapter (not the reference)

2) Flickering is going on, because of that's the trick used in such complex lissajou shapes. For example, quite at the beginning you see two triangle-like lines that then form a cross. So you are seeing two lines, right? No, it's acutally one line that's changing position faster than your eye can see. If you are able to break the connection to an oscilloscope that is not yours (maybe the FL Studio one?), you should be able to see it. All you need is a freeze frame, while the cross is displayed. On your display you probably won't see it, because you've dampened the flickering by drawing everything up to twice. So, flickering means a more precise display.

3) Thank you for pointing out the overdrawing. What you experienced is the result of the mitres. Lines and curves are drawn from point to point, and where they met at a point they are connected through mitres. The default settings for those give ugly results (that "overdrawing" you saw). While in green you can't change them (or I wouldn't know), in Ruby you luckily can. It will be in the next version of the display (this was just a quick poc, see above ) FYI, the limit for green to avoid the mitre effect is not 0.1, but 0.125. That's because the default grid setting is 8, which means 1 grid unit represents 8 pixels. 1 pixel therefore is 0.125. Everything below 0.125 is still drawn as 1 pixel.

I also think it looks better curved, that's why I used it in the demo. But it is less precise, so may not show what the original author intended you to see. Maybe I'll make it an option, so everyone can choose whatever is preferred.

Also, because of your post I was closer looking at the current version I'm working on, and found that I was drawing the frame data 3 times. And I already wondered about the high cpu usage. Now it's back to normal, so thank you

Announcing the Quilcom DEVILISH: DEVelopment Interface for LISsajou Harmony

I made this to be used as a console for Lissajou Art. It's prepared in such a way as to make it as easy as I could figure out for others to add in their own modules. It's indefinitely expandable: Just copy and past new 'empty' module boxes and fill them with glorious and clever stuff. Dead easy (I hope) to edit the selector name and output to enable your module's GUI on the front panel. The existing empty modules are ready to go.

Console features;

MIDI interface preset to monophonic with trigger options
Test note can be turned on/off over full MIDI range
Pitch Bend range can be set
Static FM osc
Modwheel FM Osc
Portamento (Glide)
Variable Left/Right swap
Variable volume/size
X/Y joystick shift for the display. Can be set to default centre by double click
4 Multi stage envellopes for width/height/Left/Right automation. These can be shown or hidden.
Preset Manager to save the state of the whole DEVILISH. This also saves any images drawn in the Magic Writer in the presets
Has MIDI and stereo audio inputs and audio outputs
Each module can be overall muted or left on so different modules' signals can be mixed
Each module contains a box to enter comments for the module/preset and the comments are stored in each DEVILISH preset.

Unison +2
This new module features 2 synths for creating many basic Lissajou figures. Each one has a range of waveforms and a pitch envelope P-ENV which can be shown/hidden and enabled/disabled. The static Phase settings affects the display rather than the sounds produced and can make a huge difference to the image produced. Surprisingly filter sweeps etc seem to be a potentially useful addition to the display patterns and are worth experimenting with.
In addition there is a Unison generator using 7 oscillators, the type of which is selectable. There is spread detuning (the 'centre' osc is always true to pitch) and phase spread. Also the width control is not amplitude but stereo spread, again with the middle osc being panned centrally.

Boinger
This is a bouncing spring emulator, kindly improved drastically by Martin V who did the lovely code modules and more.

Magic Writer
This module allows you to create freehand drawings and text in real time, and displays the result on the Lissajou Display (kindly advanced by PHI with more to come from Tulamide I expect!). Improvements here are the DEVILISH presets now store the images produced, so each preset will contain the drawing in the module at the time when saving any preset.

I've made a few presets to show the basics but this needs to be played around with to enjoy properly.

I imagine the way forward is to create modules dedicated to specific tasks, rather than attempting to make a universal tool that does everything. This is why I made this DEVILISH console.
I envisage recording audio clips that achieve various actions and then using one's favourite DAW to piece them together into something hopefully entertaining.

This topic has grown into an open project and I'm delighted to see the major players here are getting involved.

Do whatever thou wilt with the DEVILISH and any suggestions, comments, feedback, wish lists etc will be VERY welcome.

Have fun!

EDIT: Here is the final release of the DEVILISH (DEVILISH 1st). For more information see later in the thread. This has an improved Magic Writer.
https://www.dropbox.com/s/l5o3dlsdjbua8 ... 1.zip?dl=0

Cheers

Spogg

tulamide wrote:Flickering is going on, because of that's the trick used in such complex lissajou shapes. For example, quite at the beginning you see two triangle-like lines that then form a cross. So you are seeing two lines, right? No, it's acutally one line that's changing position faster than your eye can see. If you are able to break the connection to an oscilloscope that is not yours (maybe the FL Studio one?), you should be able to see it. All you need is a freeze frame, while the cross is displayed. On your display you probably won't see it, because you've dampened the flickering by drawing everything up to twice. So, flickering means a more precise display.

I don't believe this is correct. To my understanding you can't draw non-contiguous shapes with this method. Think about what the drawCurve method is doing. It draws a line between every point. There can be no jumps. If you scale the input down slightly (e.g. multiply by .98 or something) you can see on the display that the two lines you're describing are connected by a line drawn around the edge of the boundary. Likewise every shape in the sequence appears to be formed from a contiguous line.

I don't know exactly how your frame draw method is drawing points, but I do know this. Knowing that in my experience the tick100 prim puts out "around" 60 ticks per second, I calculated simply 44100/60 to get 735 as the number of samples that would need to be buffered and drawn per tick for the display to look correct. So with the green display set to that value, it did indeed look "about" right. I "rounded" it up to 1024 because of course the ticker is so unstable as you said and it looks more consistent that way. Setting a value lower than 735 and you get a "flickery" result that's actually skipping chunks of the signal. And that looks exactly like your display did, in my testing of it. For instance when the Death Star is drawn, on your display I only see chunks of it at a time rather than the appearance of a full Death Star.

Now of course since your method is different the exact cause of this is probably different. I suspect that the audio frames you've described are not lining up with the draw frames, meaning it's handling all the audio but only actually drawing as many frames as it can and dropping the rest. It doesn't sound to me that there would be any inherent correlation between audio frames and drawing or monitor refresh rate. That is just my guess.

While in green you can't change them (or I wouldn't know), in Ruby you luckily can.

That's good news!

Perfect Human Interface wrote:I don't believe this is correct. To my understanding you can't draw non-contiguous shapes with this method. Think about what the drawCurve method is doing. It draws a line between every point. There can be no jumps. If you scale the input down slightly (e.g. multiply by .98 or something) you can see on the display that the two lines you're describing are connected by a line drawn around the edge of the boundary. Likewise every shape in the sequence appears to be formed from a contiguous line.

I know, and I didn't say it were non-contiguous. I try to explain it in another way.
Remember what the two channels represent. Channel one is the x-values, channel two the y-values. Now, how do I make a horizontal centered line?
By sending 0 on channel two, while channel one runs from -1 to 1.
And how to draw a vetical centered line?
By sending 0 on channel one, while channel two runs from -1 to 1.

DAWs, and now our lissajou display too, work with audio frame buffers. Let's assume in this example it's 256 values per frame. Now, what happens when I exchange the channel data per frame?
It draws a horizontal line on frame 1, a vertical on frame 2, etc. Assuming 60 fps, this means 30 fps for the horizontal and 30fps for the vertical line. What does our eye make out of it at such high rate? A flickering cross.

This is just a simplified example, how exactly a shape is drawn in the provided kickstarter ogg might differ. But with freeze frames I could clearly see that at one point only the lower left part was drawn, followed by the upper right part on the next frame. He is using this trick just as everyone else. That's not always neccessary though. For example, sine on the x-channel, with stepping on the y-channel will produce several horizontal lines (if the connections are just out of view, which they are if you use clipping for that purpose).

Perfect Human Interface wrote:I don't know exactly how your frame draw method is drawing points, but I do know this. Knowing that in my experience the tick100 prim puts out "around" 60 ticks per second, I calculated simply 44100/60 to get 735 as the number of samples that would need to be buffered and drawn per tick for the display to look correct. So with the green display set to that value, it did indeed look "about" right. I "rounded" it up to 1024 because of course the ticker is so unstable as you said and it looks more consistent that way. Setting a value lower than 735 and you get a "flickery" result that's actually skipping chunks of the signal. And that looks exactly like your display did, in my testing of it. For instance when the Death Star is drawn, on your display I only see chunks of it at a time rather than the appearance of a full Death Star.

That's what I was talking about in point 1 of my post. Most important: You can only tell a mean of fps (the rms, so to say). That doesn't tell you how far the ticks in between drop or raise. Also, omitting chunks of data results in banding, not in flickering. And last but not least, the audio frame size for ds out is 256. With your 1024 that means you will catch the same frame's data up to 4 times. Of course that stabilizes the look of the display. It also makes it less accurate.
I assume that the problems with the kickstarter ogg's death star and my display arise from several factors (don't forget the mitres!) of non-optimization and might also come from the fact that this ogg was produced with a less accurate digital oscilloscope.

Perfect Human Interface wrote:Now of course since your method is different the exact cause of this is probably different. I suspect that the audio frames you've described are not lining up with the draw frames, meaning it's handling all the audio but only actually drawing as many frames as it can and dropping the rest. It doesn't sound to me that there would be any inherent correlation between audio frames and drawing or monitor refresh rate. That is just my guess.

Correct, only the audio data is assured to be right on time. If drawing is interrupted, things get lost. That's the same for Ruby and green. And I'm not sure about the synchronity between the two channels, beacuse DSPr didn't describe what FS is doing with it. It should be sync'd, but if it isn't that's another factor that may show unexpected results.

Let's examine this again with the next version!

tulamide wrote:DAWs, and now our lissajou display too, work with audio frame buffers. Let's assume in this example it's 256 values per frame. Now, what happens when I exchange the channel data per frame?
It draws a horizontal line on frame 1, a vertical on frame 2, etc. Assuming 60 fps, this means 30 fps for the horizontal and 30fps for the vertical line. What does our eye make out of it at such high rate? A flickering cross.

This is true, but it's a different flickering you're describing than what is the primary issue I'm seeing. Assuming the draw rate is fast enough that "should" be fine as long as all the data is represented. So as you say, if we draw all the data perfectly synced to the redraw rate and no more, that could be considered "more accurate," while drawing more than that could be considered in a sense "more stable."

What we don't want is to be missing data, drawing less than what is there. You may call that "banding;" well it looked "flickery" to me. So it's good that we can make that distinction.

I believe though there is a misunderstanding of the usefulness of the audio frames as you've described them. You've stated that the advantage is that it allows us to sync to audio, but I'm pretty sure at this point what we want is to be able to sync to the redraw rate.

We basically have two primary goals: 1) Redraw as fast as possible, and 2) draw all of the data without missing any between redraws. And then a secondary goal would be to not "overdraw" any data that was already drawn between draws.

The first two goals are achieved with the green display, as long as the ticker maintains a reasonable output (a Ruby ticker could be used in place; that's not the issue). The third goal would only be possible by syncing to the redraw rate somehow. Meaning a sample buffer would fill until the next frame is ready to be drawn and then draw it, regardless of the time it takes. Or another possibility would be if you could lock the sample buffer to e.g. 60 ticks per second and then make sure you're drawing at at least 60 fps. The redraw rate needs to meet or exceed the sample rate/number of samples buffered, or else some data is not drawn.

So if as you say the audio frame size is 256 samples, at 44.1Khz you would need to draw 172 fps in order to not lose data.

Also when you say, "the audio frame size for ds out is 256. With your 1024 that means you will catch the same frame's data up to 4 times," this isn't correct, as it would be 4 different frames' worth of data collected.

One final point, probably important. I've gathered from what you've written that the audio frame you're describing is the same as the "buffer length" setting for the audio device. Given that people set this differently, won't that give different results under your method?

Perfect Human Interface wrote:

tulamide wrote:DAWs, and now our lissajou display too, work with audio frame buffers. Let's assume in this example it's 256 values per frame. Now, what happens when I exchange the channel data per frame?
It draws a horizontal line on frame 1, a vertical on frame 2, etc. Assuming 60 fps, this means 30 fps for the horizontal and 30fps for the vertical line. What does our eye make out of it at such high rate? A flickering cross.

This is true, but it's a different flickering you're describing than what is the primary issue I'm seeing. Assuming the draw rate is fast enough that "should" be fine as long as all the data is represented. So as you say, if we draw all the data perfectly synced to the redraw rate and no more, that could be considered "more accurate," while drawing more than that could be considered in a sense "more stable."

What we don't want is to be missing data, drawing less than what is there. You may call that "banding;" well it looked "flickery" to me. So it's good that we can make that distinction.

I believe though there is a misunderstanding of the usefulness of the audio frames as you've described them. You've stated that the advantage is that it allows us to sync to audio, but I'm pretty sure at this point what we want is to be able to sync to the redraw rate.

We basically have two primary goals: 1) Redraw as fast as possible, and 2) draw all of the data without missing any between redraws. And then a secondary goal would be to not "overdraw" any data that was already drawn between draws.

The first two goals are achieved with the green display, as long as the ticker maintains a reasonable output (a Ruby ticker could be used in place; that's not the issue). The third goal would only be possible by syncing to the redraw rate somehow. Meaning a sample buffer would fill until the next frame is ready to be drawn and then draw it, regardless of the time it takes. Or another possibility would be if you could lock the sample buffer to e.g. 60 ticks per second and then make sure you're drawing at at least 60 fps. The redraw rate needs to meet or exceed the sample rate/number of samples buffered, or else some data is not drawn.

So if as you say the audio frame size is 256 samples, at 44.1Khz you would need to draw 172 fps in order to not lose data.

Also when you say, "the audio frame size for ds out is 256. With your 1024 that means you will catch the same frame's data up to 4 times," this isn't correct, as it would be 4 different frames' worth of data collected.

One final point, probably important. I've gathered from what you've written that the audio frame you're describing is the same as the "buffer length" setting for the audio device. Given that people set this differently, won't that give different results under your method?

From what you wrote it seems there's some basic misunderstandings. I can't explain them all (takes too much time), but I can tell you these few things:

"Also when you say, "the audio frame size for ds out is 256. With your 1024 that means you will catch the same frame's data up to 4 times," this isn't correct, as it would be 4 different frames' worth of data collected. "
You didn't get the point. You grab 1024 data, but a frame is only 256. Since you can't look into the future, you get a new frame and 3 old frames. Next time again 1 new frame, 3 old frames (You now already draw an older frame 2x), next time the same (now drawing one of the old frames the third time), and again (drawing one of the old frames for the fourth time, before it is finally out of reach)

What we don't want is to be missing data, drawing less than what is there
That's what can't happen when sync'd to audio. A new frame is triggered, so each time a frame arrives it is drawn. You don't have that possibility with green. There you can only assume you have cought all data.

One final point, probably important. I've gathered from what you've written that the audio frame you're describing is the same as the "buffer length" setting for the audio device. Given that people set this differently, won't that give different results under your method?
No, since no matter the buffer length, an audio frame is drawn when it is ready to be drawn. The data itself doesn't change, only the frame length. In green however this can indeed be a problem, since you are not sync'd to audio, so might draw the same data over and over again (but you don't want that because of cpu load!)

As I said in my last post, why theorizing, better let's examine the results of the next display.

tulamide wrote:What we don't want is to be missing data, drawing less than what is there
That's what can't happen when sync'd to audio. A new frame is triggered, so each time a frame arrives it is drawn. You don't have that possibility with green. There you can only assume you have cought all data.

So it's drawn 172 times per second?