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 :")
Hello,
I just got the Patch module. i picked it up hoping to load some Pure data drum sounds into it and creating a drum synth module
But seem to be having trouble getting anything to load.
I am using a Macbook pro.
I can load the example patches fine.
Everytime it try to flash my patch or any patch that i create. even just a simple osc~ to Dac~ i get these type of errors:
__pow~f requires perf information.
__pow~f requires perf information.
__sqrt~f requires perf information.
make: *** /Users/brain/Desktop/pd2dsyGUI/data/examples/gui_projects/patch/Daisy: No such file or directory. Stop.
it tells me to check the _build.txt file and this is what is says:
make: *** /Users/brain/Desktop/pd2dsyGUI/data/examples/gui_projects/patch/Daisy: No such file or directory. Stop.
Ive watched the video of the guy loading his own patch on it just fine and even copied it exactly and im getting nowhere.
Its really quite frustrating .
If anyone can help me get this going . That would be great.
Hi tenshun!
I would be happy to look at this closer with you.
It’s odd that you’re getting an error just with [osc~] to [dac~].
Where are you saving your patches?
And I also recommend using https://plugdata.org/
It has a compile mode that tells you when you’re using an object that’s unsupported. You can also flash from that app itself. It’s super convenient!
Hello Takumi,
I recreated my patch on Plug Data .8.0 & was able to upload using the compile menu. Selecting the Patch Init module.
As for Pd2dsy, i was able to load the demo examples but when trying to create a simple patch it would give me problems.
I had the files saved in the same folder as the patch examples of the pd2dsy gui folder.
For now i will just have to use Plug Data to transfer my ideas to Daisy.
1 Like
Using plugdata is encouraged so I’m glad to hear that it’s working for you.
If you do want to troubleshoot pd2dsyGUI again, please feel free to let me know any time. If you do, you can share a screenshot of what the patch looks like.
Otherwise, enjoy using plugdata with the Daisy!
1 Like