Sequencer.pd Hi, I am a pure data novice, I followed a Sound Simulator tutorial and made a 16 step sequencer with three different tracks. I seem to be getting an overwhelming amount of lag, especially when I increase the BPM. I'm wondering if there's optimization techniques that I'm not aware of that I'm not following in this patch or if this is simply too much for Pure Data to handle. I tried increasing delay time, increasing the buffer size, increasing minimum processing power on my laptop, to little avail. I use a Minifuse 2 and have the ASIO selected as my input and output. Thanks in advance.

@ionicle Welcome to the forum...!
Stopping the [metro 10] that is banging [snapshot~] seems to relax Pd.
I was having trouble even editing your patch on my I7 laptop, even with DSP turned off.
I modified this part so that it does not run unless you start the metro...

Here is your patch with the change made.......
sequ.zip

I also changed the counter...... as at some point the number going into [%16] would become very large.
You need to keep the [count] object in the same folder as your sequencer. It is what we call an abstraction.... you can use it many times..... like a sub-routine.
I hope that helps get you going again with your patch.
David..

@whale-av said:

Stopping the [metro 10] that is banging [snapshot~] seems to relax Pd.

I have no issues with this patch on linux, patch peeks out at 5% cpu when I adjust tempo and no lags or drop outs or issues editing. This could be a bug in the Windows version of pd or perhaps just an issue with how Windows schedules and manages jobs? I assumed it was one of those issues with ASIO that you help people with so often so did not respond before.

@oid My mistake....... opened in extended by double-clicking..... so no tempo message for [metro].
I thought it was trying to run rather fast........
David.

@oid On Windows Pd sometimes runs weirdly slow when the selected audio interface is unhappy for whatever reason. It's usually accompanied with terrible sound or silence which @ionicle didn't mention, so I was also hesitant to suggest that possibility. @ionicle: maybe try selecting a different output to see if you get better results?

hi, it doesn't have anything to do with the audio, it is because the engine for the UI is simple (TK) and will slow down a computer a lot when being updated faster than the computer monitors refresh rate. TK isn't really meant to draw graphics that fast but pure data allows you to send updates to UI immediately at audio rate. I even have a gaming desktop and if I crank the tempo up to 600 PD starts using a ton of CPU and stops responding.

so cheap monitors typically are at 30-60hz, lets just stay safe and say 30 hz - hz to seconds is 1/30 = 0.033 to millis is *1000 = 33 aka below [metro 33], 1/60 is 16.7 aka below [metro 16.7], now if you had a 240hz monitor you could go a lot lower but its probaby easier to avoid updates to UI below [metro 33] and for sure not below [metro 17]

Theoretically it's not frozen but because it continues to get updates But because there's nothing in the future thats going to slow it down it is frozen until I kill wish in the task manager or reboot.

UI includes - number boxes, bang objects, toggles, h/v radios, sliders,
for your patch its all the bang updates. I'll give you an updated patch to try out
l

fortunately I know a bunch of shortcuts - using CTRL-K to hook up the two selected, then using shift before wiring to put many into one (shift with wiring can do a lot of neat things, as with cut/paste to remove wires)

here try this one - was able to run at 1000 BPM with it only slogging but still running ok, had to remove bang updates, raise metro into any UI and made the number boxes smaller

sequencer-NoUI.pd

the rub is - UI updates are really useful! I use them all the time to see what a patch is doing and never avoid doing that. Here's a way to have them for debugging only - what you do is avoid hooking them up in between objects instead put them to the side, even added a toggle to turn them on or off. Notice how much CPU it uses haha (the load-meter is built into PD its below test audio and midi)

testUI.pd

@fishcrystals At 2000 bpm I get under 13% cpu usage on wish with my cpu's governor set on powersave, I started up gimp and took the screen shot while it was running and gimp took no longer than normal to start up. This is on a X13 thinkpad. I think you got something going on or the Windows wish is not very good.

@oid its been sloggy since switching to a 60hz 4k TV, the way windows does scaling doesn't help either.. but its nice to have all that real estate

@ionicle I agree with oid....... windows wish is not great.
To make up for my bad post above....... here is your patch using abstractions...... seqo.zip
It automatically saves your patterns, and you can easily add more drum sounds without the screen becoming cluttered.
You might find it hard to understand how the abstractions work. There is some help for that here...... https://forum.pdpatchrepo.info/topic/9774/pure-data-noob and then especially further down that thread... here....https://forum.pdpatchrepo.info/topic/9774/pure-data-noob/4
Once you understand the use of abstractions you will be able to build patches faster and more easily..!
David.

had to see if what you both say is true about windows

switched down to 1920x1080 and ran my stripped UI patch at 100000 BPM with out going above 9% cpu

putting the tempo up to 1000000, at 1e+07 it started hovering around 20% cpu.. at least until the counter hit 1.67772e+07 and stopped at the 32 bit floats limit of being able to add 1 and quit

on any computer 4k is an exponential increase of pixels which is a strain on TK, a cross platform UI system , and running with a non 100% pixel scale is also extra work

i am sorry for the late response, but wow, thank you everyone for the help. all of your suggestions have definitely helped