Been playing with Meander all morning- what a wonderful module! Thank you for releasing it. An indication of how well you’ve done is that I was able to create a very nice patch with no documentation (at the time) available. That’s good design and engineering…
1 Like
Seems I found a bug: https://www.facebook.com/terry.billington.5/videos/o.122795801713906/10220940853290433/?type=2&theater¬if_t=video_processed¬if_id=1579858853490011
Should I open an issue on github?
For better or worse, Meander makes no effort to return a parameter to prior or default value when the CV input is removed. The parameter stays at the last value set by CV. Is the sound in the FB video intentionally noisey/glitchy, or is that coming from the module under some condition.
I have V1.0.3 submitted to the plugin library. In that I made some changes to get rid of occasionally seen glitching audio.
1 Like
Since I have been working on this issue for several days and still do not fully understand it, I am going to ask the question here:
Occasionally I have episodes of intense audio noise while my module is running. This seems to be related to disk I/O and can be affected by other programs such as the web browser. But, sometimes it seems the intense glitching is arising within my module and may last for a second or two or occasionally even longer and I stop Rack in that case.
What are the most common sources of this type of noise? I have some theories, but here is my main theory:
Sometimes when inputs are read via getVoltage() or parameters are read or changed via getValue() or setValue() or some combinations of these, the intense glitching starts and seems to be disk read or write related. I have moved almost all CV input processing out of my module process() function per sample section and into a ClockDivider.process() function with a division factor of 512 which works for Meander since no DSP audio processing occurs, other than DSP clocks and timers.The glitching seems improved, but still happens occasionally.
Can audio noise being caused by doing port I/O or parameter getting or setting in the module process() at DSP sample frequency?
I have wondered if this is an autosave issue. Is autosave just timer based, or does it try to keep up with parameter changes as they happening? My test patch is a large patch and Meander has lots of parameters (~80).
I’ll leave it at this as I may have this all wrong and someone can point that out to me… kindly:)
Not sure much can be done about that other than not using a browser while making music. Any audio program / program will spike when you open a web browser, browsers are not the most efficient in terms of RAM, when the RAM gets stolen from audio buffers they need to recalculate and account for the lost RAM. Also one of the reasons why studios have dedicated machines for processing audio, you’d be hard pressed to find Internet connection on a Studio’s control room Machine.
1 Like
Here comes random stuff:
Does this problem only happens with your module, or does it happen all the time on your system?
Many people find this paper of mine useful: https://github.com/squinkylabs/SquinkyVCV/blob/master/docs/efficient-plugins.md
If your web browser and other things are interfering with the audio you should set the rack engine thread to real-time priority. You should anyway (it’s in the engine menu).
Processing CV every 512 samples sounds suspicious. That means if you set your system to 32 sample buffers most of the buffers will not get hit with your “cv tax”, but it will come crushing down into one buffer’s processing time. If you really need to do this, either spread it around (do 1/10 of it every 50 samples), or do it on a worker thread (difficult and not always a great idea) or ideally make it just more efficient.
You must measure how long your processing takes to see if there is a problem. And measure how long it takes you to draw your panel. You have a lot of graphics, and font rendering can take a lot of time.
There are many ways so solve all these problems, but first you have to find out what the problem is.
2 Likes
@Coirt thanks. I understand the issues with running browsers etc. But, I suspect that a module could cause glitching itself and that is what I am most concerned about.
@Coirt: That shouldn’t be true it you set rack to run at realtime priority. Back before rack had this feature I had a plugin called “Thread Booster” that was pretty popular that raised rack’s engine thread to realtime priority. I found that it made rack immune to interference from browsers.
1 Like
@Squinky thanks. As a reminder, Meander does no sound processing but is rather just a complex CV, trigger and gate output sequencer based on some fairly complex non-DSP calculations. That’s why I can get away with using a 512 sample CV process()… I think. Am I misinterpreting something here? Should “buffer processing” matter to Meander? I.E., is Rack using those same buffers external to my module such that my module could impact the Rack buffer processing?
I’ve read your paper a couple of times and will do so again. My problem is that the problem does not manifest itself often. It seems to occur more often when I am doing CV input handling, but I haven’t pinned down just when it occurs. I can go for a relatively long time without seeing the problem.
I should note that this only started last week at the same time the massive Windows security update came out. MS changed a lot of OS and hardware parameters back to default power saving settings rather than my Alienware gaming machine performance settings. Things like powering down USB ports etc. Of course this was at the same basic time when I added all of my CV input ports, so that is why I am concerned.
I may be putting to much into this as it might all be in the OS.
Ah, I see that thread real time priority setting. I thought that was a heading text. I selected it and will see if that helps. Learned something! Thanks.
Yes, but it still does matter. The processing functions of all the plugins in the patch still gets called every audio sample, and there is still an audio buffer under the covers. If the sum of the processing time for all the modules in a given buffer is longer than the time it takes the buffer to play, then you will get an audio glitch. Even though you aren’t processing audio you are fighting for CPU with everyone else who is doing audio processing.
The “Spikes” section of my paper is about this (more or less).
You can probably do some easy experiments if you don’t have a way of doing detailed measurements of your code directly. What to the rack CPU meters say if you do the processing every call instead of 1/512? does it use way more than 100% of the CPU? Or looking at it a different way - does the nature of the dropout change radically if you change the audio buffer size?
But direct measurement of your code is really the way to go. But it can be difficult, especially if you didn’t design for that up front.
I should clarify my ClockDivider usage. The psudocode for my usage is:
Module.process()
{
if (ClockDivider.process())
{
}
}
All other stuff still happens once per sample.
The CPU usage is 1.6% with my ClockDivider set to 512 and is 3.7% with the ClockDivider set to 1. This is about what I expected. All I am doing in the ClockDivider.process() loop is to run through the array of CV input ports, see if they are connected and if connected, check the input voltage and see if that is different from the last check and if so do a param.SetValue() and maybe some other things but nothing too time consuming.
Since my module stays down between 1-2% almost all of the time, I have not bee too concerned with profiling. I originally uses system times to profile the critical functions in Meander, but I removed that code as it did not seem necessary. I can always put it back in if needed.
BTW, this morning Meander went into a audio glitching mode for several seconds and during that time the module CPU usage got as high as 9%. That is not too high but may still be a symptom of something occasionally going on in the module.
I should have also said that the module processing time was 0.33uS in both tests.
For the time being, I’m going to assume this is a Windows problem. Every thirty minutes or so my Focusrite Scarlett 6i6 audio interface stops working and has to be power cycled to get it back. It just now did that while I was testing Meander and that created the long audio glitch time with the CPU usage going up to around 10%. This Focusrite issue began with the Windows update last week and my subsequent attempts to get things back to normal. I have exhaustedly scoured Windows for a device driver set to power down for energy savings. I need to confirm the audio interface quits working eventually without Rack running.
Yeah, just confirmed that the audio interface quits working after some number of minutes even with Rack not running.
Options are re-configuring windows to the settings they were previously on or system restore. As you said a Windows security update changed lots of settings like power settings and such. Or see if there are driver updates for the scarlett https://customer.focusrite.com/en/support/downloads?brand=Focusrite&product_by_range=506&download_type=all
Yeah, I updated the Scarlett driver yesterday. I’ve been in this boat before. It takes a while to figure things out. I will go through everything again. I also had to do BIOS reflash on my computer as my existing Alienware BIOS was incompatible with MS’s new power management methodolgy. Too many things at one time. Thanks.
That’s a lot of changes alright, best of luck!
Please ignore my questions regarding noise in your FB video. That was all originating on my end. Not sure how, but I have several unexplained audio issues.
Sure no problem… Thanks for your response.