electro-smith / pd2dsy Goto Github PK

Requested feature, and an interesting one at that.

Not sure how we'd manage any string formatting that goes a long with it, but if pd messages work like max messages than we could just parse the messages as strings and schedule them for output periodically.

Hi

All seems to go well, from my daisytest.pd file Pd2dsy.py does create a new directory with diasy_boards.h daisytest.cpp and Makefile as the contents. When I then run make, I get the error underneath. It seems to look for Heavy_daisytest.hpp, a file which wasn't created, did a search in case it was put elsewhere. What do I probably do wrong?

C:\Users\andye\pd2dsy\daisytest>make
mkdir build
arm-none-eabi-gcc -c -mcpu=cortex-m7 -mthumb -mfpu=fpv5-d16 -mfloat-abi=hard -DUSE_HAL_DRIVER -DSTM32H750xx -DUSE_HAL_DRIVER -DHSE_VALUE=16000000 -DSTM32H750xx -Ic/ -I../libdaisy -I../libdaisy/src/ -I../libdaisy/Drivers/CMSIS/Include/ -I../libdaisy/Drivers/CMSIS/Device/ST/STM32H7xx/Include -I../libdaisy/Drivers/STM32H7xx_HAL_Driver/Inc/ -I../libdaisy/core/ -I -O2 -Wall -Wno-missing-attributes -fasm -fdata-sections -ffunction-sections -MMD -MP -MF"build/system_stm32h7xx.d" -std=gnu11 -Wa,-a,-ad,-alms=build/system_stm32h7xx.lst ../libdaisy/core/system_stm32h7xx.c -o build/system_stm32h7xx.o
arm-none-eabi-gcc -c -mcpu=cortex-m7 -mthumb -mfpu=fpv5-d16 -mfloat-abi=hard -DUSE_HAL_DRIVER -DSTM32H750xx -DUSE_HAL_DRIVER -DHSE_VALUE=16000000 -DSTM32H750xx -Ic/ -I../libdaisy -I../libdaisy/src/ -I../libdaisy/Drivers/CMSIS/Include/ -I../libdaisy/Drivers/CMSIS/Device/ST/STM32H7xx/Include -I../libdaisy/Drivers/STM32H7xx_HAL_Driver/Inc/ -I../libdaisy/core/ -I -O2 -Wall -Wno-missing-attributes -fasm -fdata-sections -ffunction-sections -MMD -MP -MF"build/startup_stm32h750xx.d" -std=gnu11 -Wa,-a,-ad,-alms=build/startup_stm32h750xx.lst ../libdaisy/core/startup_stm32h750xx.c -o build/startup_stm32h750xx.o
arm-none-eabi-g++ -c -mcpu=cortex-m7 -mthumb -mfpu=fpv5-d16 -mfloat-abi=hard -DUSE_HAL_DRIVER -DSTM32H750xx -DUSE_HAL_DRIVER -DHSE_VALUE=16000000 -DSTM32H750xx -Ic/ -I../libdaisy -I../libdaisy/src/ -I../libdaisy/Drivers/CMSIS/Include/ -I../libdaisy/Drivers/CMSIS/Device/ST/STM32H7xx/Include -I../libdaisy/Drivers/STM32H7xx_HAL_Driver/Inc/ -I../libdaisy/core/ -I -O2 -Wall -Wno-missing-attributes -fasm -fdata-sections -ffunction-sections -MMD -MP -MF"build/daisytest.d" -fno-exceptions -fasm -finline -finline-functions-called-once -fshort-enums -fno-move-loop-invariants -fno-unwind-tables -std=gnu++14 -Wa,-a,-ad,-alms=build/daisytest.lst daisytest.cpp -o build/daisytest.o
daisytest.cpp:5:10: fatal error: c/Heavy_daisytest.hpp: No such file or directory
5 | #include "c/Heavy_daisytest.hpp"
| ^~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [build/daisytest.o] Fout 1

Kind regards
Andy

Hi,

I tried to generate a code for a Daisy Seed but I get an error

$ python pd2dsy.py --board patch examples/PdFiles/saw_test.pd
Generating project in ".\saw_test"
  1) Error c2daisy: Unknown parameter "ChannelA"
(pd_env)

Win 10 home edition
$ git log --oneline
d20c6ba (HEAD -> master, origin/master, origin/HEAD) consistency in commands for venv activation

I get the error above when following the installation guide. I'm using Debian 11 with Python 3.9.2. I execute the terminal command below while in the pd2dsy folder

source ./pd_env/bin/activate

Hi!

Will the support for kxmx_bluemchen come in the future? I'll receive the module soon and would like to try a few PD patches of mine, but I'm not sure if I can and how...

Thanks,
Roberto

On the gui_installer branch, I've run into issues attempting to create a program with "Size" selected for RAM with the STM32 bootloader. For now I've just disabled that option.

For some reason, the above configuration on the Daisy Field results in unreliable behavior from the LED. From my testing, the button bang itself is actually perfectly reliable, but somewhere in the chain an error causes the LED to only turn off sometimes. The error isn't entirely random, since at the very least it's always on when it should be.

The cause of this bug isn't obvious to me at the moment, and it seems to be pretty subtle.

As in shutil.copytree(os.path.join(output, 'daisy'), output, dirs_exist_ok=True). This breaks on version 3.7.3.

For some reason, the filter_map_ctrl function throws an exception when using python 3.8.10, which is the version shipped with my release of Ubuntu at the moment:

Traceback (most recent call last):
  File "daisy_board_gen.py", line 161, in <module>
    template_code = generate_target_struct(infile)
  File "daisy_board_gen.py", line 122, in generate_target_struct
    replacements['init_single'] = filter_map_ctrl(components, 'typename', 'daisy::AnalogControl', 'init_single')
  File "daisy_board_gen.py", line 51, in filter_map_ctrl
    return "\n\t\t".join(map(lambda x: x[init_key].format_map(x), set))
  File "daisy_board_gen.py", line 50, in <lambda>
    set = map(lambda x, i: x | {'i': i}, set, range(1000))
TypeError: unsupported operand type(s) for |: 'dict' and 'dict'

Oddly enough, doing a pointless list comprehension before the second line in the function fixes the issue ([x for x in set]). Maybe it's a bug in how python used to handle filter objects?

Anyway, this is all not very relevant since the latest python release is 3.10. I'm just putting this here in case this issue crops up in the future.

Hello folks.
When devising repeatable patch building from a different repo i found that being able to do the above is helpful and allows for intermediates like the generated code to go to build directories for cleanup etc.
Interesting?
My fork contains a branch dev that implements something that works for me.
It adds --out_dir to allow output relocation.
It performs os.chdir() to assure that program-relative paths resolve.
One side effect of these changes is enhancing the rewrite of the target Makefile to point to libdaisy no matter where the generated output goes.
There are still places where one needs to pass absolute paths to the program (--out_dir being one), but these could be fixed up to allow relative paths to work too.

Hi. When will Field support be coming do you think? I'm deciding between getting a Patch or Field and would like to use Pd

There are many uses where this would be ideal. And a few people have mentioned that they would prefer it as well.

Hey there,

I've been working on an updated hvcc using python3 with some new targets (dpf): https://github.com/Wasted-Audio/hvcc
Would you be interested to get your pd2dsy wrapper integrated as a new target?

I don't have a daisy myself to test (yet), but it seems your templating is relatively simple at least.

Let me know what you think.

Seems like if you have a folder created already, and try to rerun pd2dsy.py to fill that folder again (maybe just a tweak to the PD patch, etc.), the script fails.

I think this is fixed in the upstream python3 version, but worth double checking.

If our timeline for the new version bumps out further than a week or so from now we should do a fix on the current version in the meantime.