High-resolution oscilloscope

[tester]

AudioDevice primitive + AfterLoad primitive should do. The first one probably detects changes in default windows sound settings, and the seconds resets the scope each time when schematic/app is loaded. Can it be simpler? I guess not.

[cyto]

AudioDevice primitive + AfterLoad primitive should do. The first one probably detects changes in default windows sound settings, and the seconds resets the scope each time when schematic/app is loaded. Can it be simpler? I guess not.

For an exported .exe that should be perfectly fine. I would worry about using that in a VST, though. How many people make changes to their audio setting from within a plugin? Not many, I'm afraid. They would make the changes in their DAW settings. Unfortunately, the only ways I can think to detect those types of changes would be via code/asm. The routine currently in place involves a "clear audio" as the final step in the reset, so I'm afraid we would run the risk of getting into an infinite loop of audio refresh if we went that route.

-cyto

[tester]

Ah, I see - I just checked. I thought, that this one shows also which one is in use. Hmm... When dealing with VST - what the host is sending to a plugin? Is this buffer thing not host dependent?

[tester]

Just a quick question. If nothing is conneted to the scope inputs, but the scope is present in the schematic - is the scope taking CPU too or get's offline?

[tester]

Quick question. As far I remember, there was some unfinished tiny thing here, related to detecting some bufers, which caused some problems on certain soundcards. Was it solved?

I ask, because I decided to use that scope in my project (looks very cool there), so it would be great if this one works with no such issue. Right now I just added a note, that the scope may not work on certain soundcards.

[trogluddite]

Ah, yes, thanks for the reminder.
SM has not changed in this respect - finding the buffer boundaries is still tricky - but in FS, the Ruby 'Frames' should make it much easier to allocate the buffers correctly.

[tester]

I would be on finishing that part "as it is" (if possible), with no ruby, also for SM users. As far i remember/understood there were some successful attempts, just not implanted yet into the project.

[trogluddite]

I think Cyto's version posted earlier in the thread is about as far as you can go in that direction with SM - IMHO pretty much all the options have been explored to make SM read the audio the way we would like.

The fact that the current schematics work as well as they do is testament to the intelligence of Cyto and DWB - but they rely on what I would class as "ugly hacks", already going far beyond what the developers intended to be possible with SM. It has taken the combined efforts of some people with very comprehensive SM experience to get this far - it will not be trivial, and may be impossible, to take it much further.

Any solutions won't come from me, I'm afraid. I will continue to contribute here where there is common code to be shared; but FS/Ruby shows the way to a much simpler solution for this particular problem, and I am in no mood to make life hard by fighting against limitations of SM that I know will never change.

[cyto]

Tester:

I think the only thing that remains to be done too make it "as good as it can be" is what you suggested a few posts ago. Specifically, connect the triggers from the "after load" and/or "audio devices" primitives to the node that the "reset" button is currently connected to. This will at least update the thing to the user's environment when starting and/or switching audio devices. From your past work, I am assuming that you are working on a stand-alone application. This should be okay for that purpose. What worried me before was using it in a vst effect, where there are so many host-plugin issues that would be difficult to detect. You should be okay in a standalone. I'm sure there are a few of us still remaining that would test your project in some different environments for peace of mind. As trog said, this thing is heavily "hacked" (an attribute that I take great pride in! ), but I think it will be okay in most situations.

-cyto

[trogluddite]

this thing is heavily "hacked" (an attribute that I take great pride in!

He he, it is true - twisting SM to do "impossible" things can be very satisfying indeed.
But you make a very good point - when the required data is supplied by an external host, then it is right to be cautious about using this as the default solution.

[tester]

I'm doing standalone execs for offline experimentation, and vst plugins for direct sound processing. Buf as for VST - these are "reaper dedicated", i.e. don't care about other hosts. Reaper is inexpensive audio host with great possibilities (and I like their market philosophy), plus it's resistant to most issues (and automation issues too) generated by SM/FS plugins. In Reaper, the only thing I haven't figured out yet, is - what "node" (module) can be used to reinitialize plugin for rendering the file. It seems, that plugins just go continuously, just at CPU speed instead of realtime.

I awoke this topic, because i was curious if there was anything else achievable on that part. Was not my intention to insist anyone. From my own experience I know, that sometimes projects are abandoned for months (due to overwork on them and sort of that), and then something new suddenly pops out.

Thanks for gathering tips in one place, and of course - for the greatest SM scope ever made

[trogluddite]

what "node" (module) can be used to reinitialize plugin for rendering the file. It seems, that plugins just go continuously, just at CPU speed instead of realtime.

For rendering in Reaper, i always use one of these two methods...
1) Rendering - in the rendering options window choose "1 x Offline", or "Online" render modes - this will fix the render speed at "real-time". ('Online' keeps audio inputs active - e.g. if feeding in hardware effects).
2) "Save live output to disk" - from the file menu. Does the same thing, but always uses the same file format as the project recording options - so you can't make a new file with different bit-depth or re-sampling, but it's a bit quicker to set up.

I find these most reliable for SM plugins. It helps by keeping the "green" and stream parts of the plugin synchronised with each other. Because "green" events are on a 'low priority' CPU thread, the audio can sometimes race ahead of green if rendering faster than real time.
I have noticed the same problem with some other non-SM plugins too - I guess they must also use some timing systems that are not sample-rate locked.

Worth checking out the Reaper forums too - they are a bit disorganised compared to here, but Google brought up a few threads there about the subject of rendering troublesome plugins.

Was not my intention to insist anyone

No problem - does no harm to give a dormant project a little kick once in a while!

[tester]

I think we misunderstood with Reaper or I don't follow something in what you wrote. What I'd like to do - is to have oscillators resynced automatically when rendering starts. I noticed, that Repaer just continues from last position, so during the render I must click manually "resync" button in my app. I was wondering what module would send that resync trigger on switch to render mode. But I do wish to have the render at max speed. I'm rendering rather large files. Have fun!

[trogluddite]

Ah, sorry, misinterpreted the question there.

There's a primitive called "Offlline Mode" that might do it. Outputs a boolean value of when the host is "offline" - so maybe using a 'bool to true' from that might do the trick. It's green though, so not sure if the timing would be good.
If not, maybe use the stream "sample position" to check for sample number zero - but that would only work if you always render from the very beginning of the project.

[tester]

Okay, will check that, thanks.