The blocksize by default is 48 samples (at a sample rate of 48k Hz). I’m not sure how you think you can get 180x steps out of that 
So even if you can get a value every sample it still wouldn’t be at the rate that you want.
A range of 96 is still far preferable to a range of 1. (assuming I did my arithmetic right there)
Edit: I can come up with silly solutions to this, like communicating with an Arduino via MIDI to do the PWM work, but since the Daisy says it already has PWM (though I can’t figure out which pins can do it), and audio rate already gets close, it seems like there should be a simpler solution here.
If I’m not mistaken, PWM is done using STM32 timers dedicated for this purpose, so it isn’t related to the audio block size. I don’t know if libdaisy has implemented any API for facilitating this.
tele_player said:
If I’m not mistaken, PWM is done using STM32 timers dedicated for this purpose, so it isn’t related to the audio block size. I don’t know if libdaisy has implemented any API for facilitating this.
So, I think the question for JoshuaACNewman is, are you willing to write, or perhaps adapt if you can find some, C or C++ or even gasp assembler code that will be called by the ‘abstraction’. Assuming nobody chimes in with an already implemented solution.
ST probably has some example code for implementing PWM in the doc on the STM32H750IBK6 processor.
1 Like
I also wonder if JoshuaACNewman is confusing two meanings of PWM - its use to produce an analog-like output on digital pins, and PWM as used in a VCO to create a timbre animated by an LFO.
UPDATE: I looked at libdaisy - it already has software PWM (hid/led.h, hid/led.cpp) for controlling LED brightness, a comment indicates hardware PWM for the pins which can support it remains TBD (To Be Done).
1 Like
I made a perfectly serviceable audio one already that uses the DAC. That’s not the issue. The issue is in using it to communicate with a servo (and potentially using digital pins for audio as a secondary concern), which takes place at a time frame shorter than control rate allows.
I didn’t think to look at the LED library! Tuning it for servos should be really simple! Thanks! That means it’s just a matter of waiting for the hardware support to be finished, then properly proportioning the values, assuming it can operate within them! It actually requires a pretty low frequency (50Hz is standard) and the entire duty cycle range is really narrow, which is why I’ve been trying to figure out how to represent it.
Hello all, I’m aware there might be a noob mistake at hand, but hopefully, you can help me out. I have made a patch for a 4 note melody and wired my seed up with one potentiometer. The left version works perfectly. The melody starts playing at 120 bpm right away and I can control the volume with the potentiometer. But then I tried the right version, the plan was to control the bpm of the melody and seemed like a straight forward alteration. But this does not work. I have a continous noisy sound and the potentiometer seems to have no influence. It sounds like it’s playing, but extremely fast. I have tried other values instead of the * 1000 and other caps for the values, but to no avail. 
Hello Iliceth!!
The [r ctrl1 @hv_param]'s output range is 0.0 to 1.0. So the potentiometer set at 0.1 is 100 BPM, which is fine. But as soon as the potentiometer is twisted to 0.2, then it’s 200 BPM, which is a big jump. And the max BPM as of right now is 1000 BPM.
What I recommend is to test all of this within Pure Data by using the slider object (either vertical or horizontal is fine) and set the range to minimum 0 and maximum 1. Now you have a slider that outputs float values from 0.0 to 1.0 much like the knob.
Then, think about how you want to scale that value to get an appropriate BPM. I would probably do something like [vslider] → [* 120] → [+ 80] → [tempo $1 permin].
So, the slider/knob at 0.0 will equal 0 * 120 + 80 = 80 BPM
And the slider/knob at 1.0 will equal 1.0 * 120 + 80 = 200 BPM
I hope this helps!!
1 Like
Hi Takumi, thanks for your input. Everything you wrote makes perfectly sense and it’s of course a good idea to mimic the knob with the slider object to predict the behaviour. So I did, and also incorporated your suggestion on the scaling. All this helps to augment my workflow, but… it did not solve the problem unfortunately. It all goes and sounds the same and turning the knob does not have any impact, or so it seems at least. And the hardware + circuit is fine, as I can upload my left example to Daisy and get exactly what is intended again.
Remember that the @hv_params in Daisy fire continuously. I don’t know if metro gets reset at all when it receives a tempo message.
Otherwise it’s best to add a [change] after the knob so it only gets through when you are actually turning it.
1 Like
Thanks, dreamer, I wasn’t aware of that, but your remark seemed in line with my experience.
So, I added the change object directly after the knob and a different outcome was the result. Instead of the constant noisy sound, not impacted by the knob-turning, I can now impact the sound. Although, be it ranging from the original crazy noise on the one end to something that sounds similar to when I test my patch in Pure Data itself at around 1000-1200 bpm on the other end.
Fully in line with Takumi’s info, changing the scaling did not change anything further.
I noticed that if I add a loadbang for a start tempo of 120 bpm, similar to my left example, which worked then, it goes directly to the noise pattern again, so with the [change] in place and not touching the knob. Therefor, in some way it seems that the [change] does it’s job, but that there is a super high value that gets send to the [metro] at load time, which overrides or clashes with all other inputs maybe?
Hey again!
I tried out your patcher with Daisy and made some modification.
In short, the [tempo $1 permin] is tricky to use.
Try something like this instead. I can confirm that it works on Daisy!
And adjust the value scaling to your liking.
2 Likes
Thanks a lot! Works like a charm. 
My bad for sticking to the tempo object instead of trying other ways, but good to know none the less.
1 Like
I just received my Daisy Pod and got the Pod example loaded up. Excited to get going with Daisy and Pure Data.
However, I note that it uses HVCC, which is no longer maintained. The last update was in 2018. What is the plan there moving forward in terms of continuing support for Pure Data for the Daisy? Is there concern about this?
It is maintained → GitHub - Wasted-Audio/hvcc: The heavy hvcc compiler for Pure Data patches. Updated to python3 and additional generators
1 Like
Ah, I see. Thanks!
I’ll circle back to see if I was pointed to the old repository from a Daisy document.
Let me know if it was and I can update it 
Hey there Just wondering if there’s still plans to add midi support to pd2dsy? It looks like it’s been in the works for a couple years, maybe someone has some experience with a workaround?
Much less than a year. I had a prototype for it last October, but I need more input from the E-S team and others before I continue.
Not sure what you think you mean with “workaround”, but you could try those two versions of json2daisy and hvcc and report back
Hey thank you! I’m glad to hear that you’re working on it, hopefully you hear back from the people you need to keep working on it Unfortunately I’m a rookie and couldn’t get anything to compile, but I’m guessing its a user error and I’ll keep trying. I’m thinking maybe I’ll fork out the ten bucks a month and play with max msp, or even not be as lazy and brush up my c++ skills a whole heap :")