Hey everyone!
I’m encountering an issue and was hoping someone could suggest a solution or workaround. The patch I’ve created sends a signal to four different LFO types and four different timing divisions, each controlled by a switch on the right. The patch works fine overall, but the square wave LFO doesn’t respond to the timing divisions. If I remove the waveform selection section, all four LFOs respond correctly to the division switch.
Does anyone have any ideas on how to fix this?
Thanks in advance!
Can you please share the patch file? This makes it a lot easier for someone to inspect and reproduce 
Instead of using a [select] for both of these stages I’d setup an [==] on each of the spigots.
This will make more sense with your logic, as you want to open and close (0 and 1) when the exact channel is selected.
It will also save you on a whole bunch of objects and connections in the patch.
Hey Dreamer!
Thank you for the suggestion. Here’s a link to the PD file for your reference regarding the square wave division issue. The file does not yet include your suggestion, but I’m currently experimenting with it.
Thank you!
I found a fix for the square wave issue- Removing *~ 10000 from hv.lfo square got it working with the time division selector. So everything is working now, however, when divisions above 1x are engaged, there is a tiny gap at the end of each sequence. Is there a way to fix the timing so they are better in sync? Here is a link to the updated patch, along with your switch suggestions!
Thank you!
I don’t really understand why you are setting the lfo timing after the lfo’s. shouldn’t you change the timing before them to set the frequency?
What is timing other than frequency?
The timing is set after the LFOs because of the tap tempo feature (r sw1@hv_param is the tap tempo). The goal is to trigger it using either a gate signal or tap tempo. If the timing is placed before the LFOs, it works well with a constant gate signal. However, when using tap tempo alone, it requires a re-tap to trigger the new divisions. This isn’t ideal, as it would be much better to simply adjust the divisions and have them engage without needing to re-tap the tempo.
I’ve tried a few aproaches to place the timing before the LFOs, but none of them have worked very well. Do you have any ideas for how to achieve this while still accommodating the tap tempo?
The thing is that I don’t see how multiplying an lfo value gives you a different tempo 
The LFOs give a value between 0 and 1, if you multiply by say 4, they will give a value of 0 to 4 ..
Their tempo will be completely unchanged.
It’s multiplying the frequency rate, not the LFO value. Give the patch I linked to a try- It totally works, except there is the slightest delay at the end of each sequence.
The delay is almost even unnoticeable, but I’d like to get it as tight as possible.
That’s not what your “division switch” is doing. It is multiplying the output of the lfo’s which simply scales their value accordingly. I think the name is maybe chosen incorrectly. Perhaps you can call it “value scale” or something? It certainly is not “dividing” anything.
I see your timer circuit now. The problem here is that the timer will always give the output between two bangs. So if you haven’t pressed it in a while you will get a very large value.
There are probably some patches available that will do a count and average between several ticks and then reset the count after say 10 seconds. This will take some more boiler plate and figuring out of course.
If you add this to your patch you can better see what is going on:
#X obj 750 15 r cvout1;
#X obj 754 69 vsl 18 128 0 8 0 0 empty empty empty 0 -9 0 10 #191919 #ffffff #ffffff 0 1;
#X connect 0 0 1 0;
I’m not sure what you mean with “there is .. delay at the end of each sequence”, what sequence? I don’t see any delay.
I understand the multiplication should be scaling the values, and I see it working in PlugData with the code you gave me (Thank you for that, BTW). However, that’s not what happens when compiled to the Daisy- Here’s a video showing it increasing the rate, in case it’s useful for anyone.
In any case, I’ve gone back to having the time / multiplication stage first. Manually resettng the tempo might be a good idea to make sure they are completely in sync, but I’ll also experiment with some count and average patches like you suggested.
Thanks again for all your help!
1 Like
