Oopsy Custom Json tips?

Hey All! I’m sure this is a basic question but I’m trying to wrap my head around custom boards / custom Jsons and Oopsy… So maybe someone more knowledgeable might be able to lay it out for me in simple terms.

I’ve created a custom board for the Patch Sub Module. To access things properly, I’ve created a custom Json file (customboard.json) and used json2daisy which created a *.h file (customboard.h). Up till this point I’ve been using PD, so I placed the files in the right place and so far it works great with pd2dsy.

However, when I try to create a Gen~ patch and load this same customboard.h into the Oopsy loader (I click BROWSE and select customboard.h), it will flash to my daisy but not work at all. Is there something extra I need to do in Oopsy for it to recognize it? Or do I have to do something to my Json for Oopsy? Do I need to put the files in a certain place? I’m having trouble decoding this with the info from the github and other resources. Any tips would be super helpful!

I’ve tried trouble shooting a bit - Ive tried selecting Patch_sm in the Oopsy loader instead of my custom file - and thats send to my board with no problems (but of course doesnt have the proper mapping of knobs/cv of the custom board)… So the system works, just not my custom file.

Thanks in advance for any tips!

best
Doron

Inside Oopsy I loading with custom Json files.

Saved with a .json suffix.

Note the pin numbers are the numbers of the GPIO number not the physical pin.

{
	"name":"colortone_digital_15_v1",
	"defines": {
		"OOPSY_TARGET_HAS_MIDI_INPUT": 1
	},
	"components": {
		"sw1": {
			"component": "Switch",
			"pin": 8
		},
		"sw2": {
			"component": "Switch",
			"pin": 9
		},
		"sw3": {
			"component": "Switch",
			"pin": 10
		},
		"sw4": {
			"component": "Switch",
			"pin": 26
		},
		"sw5": {
			"component": "Switch",
			"pin": 25
		},
		"knob1": {
			"component": "AnalogControl",
			"pin": 24
		},
		"knob2": {
			"component": "AnalogControl",
			"pin": 19
		},
		"knob3": {
			"component": "AnalogControl",
			"pin": 22
		},
		"knob4": {
			"component": "AnalogControl",
			"pin": 20
		},
		"knob5": {
			"component": "AnalogControl",
			"pin": 23
		},
		"knob6": {
			"component": "AnalogControl",
			"pin": 18
		},
		"knob7": {
			"component": "AnalogControl",
			"pin": 21
		},
		"led1": {
			"component": "Led",
			"pin": 11
		},
		"led2": {
			"component": "Led",
			"pin": 12
		},
		"led3": {
			"component": "Led",
			"pin": 13
		},
		"led1a": {
			"component": "Led",
			"pin": 7
		}
		
	},
	"aliases": {
		"sw1_bypass": "sw1",
		"sw1": "sw1",
		"sw2_tap": "sw2",
		"sw2": "sw2",
		"sw3_FwdRev": "sw3",
		"sw3": "sw3",
		"sw4": "sw4",
		"sw5": "sw5",
		"sw6": "sw6",
		"knob1_len": "knob1",
		"knob1": "knob1",
		"knob2_speed": "knob2",
		"knob2": "knob2",
		"knob3_fb": "knob3",
		"knob3": "knob3",
		"knob4_mix": "knob4",
		"knob4": "knob4",
		"knob5_mix2": "knob5",
		"knob5": "knob5",
		"knob6": "knob6",
		"knob7_exp": "knob7",
		"knob7": "knob7",
		"led": "led1",
		"ledBypass": "led1",
		"led1": "led1",
		"ledTempo": "led2",
		"led2": "led2",
		"led3": "led3",
		"led1a": "led4"
	}
}

Thanks for the response! Unfortunately it doesnt seem to work for me… Ive tried copying your code into a new json file but still nothing. Actually, even if I go through and manually pick the daisy.patch_sm.json file from the Oopsy/Sources folder it doesnt work either - it only works if I select it from the menu of preset jsons. I assume Im missing something, but not sure why it doesnt do anything at all…
Im also curious, what do you mean by the GPIO numbers and not the physical pin? The PatchSM seems to use a numbering system with ABCD prefixes - is that what you mean?
Thanks!

By the Pin numbers Im referring to the physical pins on the seed that you have your controls (Pots and switches) connected to. The Eagle Library lists the GPIO numbers that are related to the Physical pins. I use the GPIO numbers in the .json file.
So in the example I posted earlier knob1 is listed as Pin: 25 but its actually physical pin 32 GPIO 25.

See Below.

Hi @fadedinstruments

We have an open PR on Github that has reworked the custom JSON to support different “SOMs”; essentially allowing for configuring JSON for the Daisy Seed or the Daisy Patch SM.

Previously, there were two different formats for writing JSON: one for the built-in boards, and one for “custom” boards (which is why trying to grab the built-in patch sm JSON wasn’t working as expected).

This separation has been removed in the latest update.

All of the built-in boards’ JSON files have been rewritten into this format as well (e.g. Daisy Pod, Daisy Patch.Init()), and can serve as examples alongside a new wiki article that goes over the details of how to work with custom JSON within oopsy.

We are currently still in the process of testing and reviewing this ourselves, and will be working on wrapping this update up over the next week or so.

Any feedback, bug reports, questions, etc. are all welcome.

2 Likes

Thanks! Sorry about the delay - its been a busy two weeks… Im just getting to this now and it still doesnt seem to be working for me. I feel like my custom Json is okay - I followed the instructions on the wiki article you posted and compared it to the examples of the Patch_Init.json - but it still doesnt work. I downloaded the Oopsy forks - oopsy-main.zip and oopsy-sensors-update.zip - but those work at all for me (even the included Patch_init presets dont function for me - whereas the older Oopsy I’m able to use the Patch_sm preset). Is this maybe still being worked out or am I messing things up?
Thanks again - I know Im a beginner here so some things are still difficult for me to understand!

1 Like

Okay! I figured it out and its working now! I’m sure theres a better way to do this… But I just copied the LibDaisy had to copy the libdaisy folder from the sources folder of the old Oopsy to the newer oopsy-sensors-update and it works :slight_smile: Thanks!

Hi, New here/Loving the daisy. Have a patch SM. Built a custom board but failing spectacularly on the custom json side so this is a request for help. I get back below message, but all I’ve done to the json is changed gate_out_1 to be gate_out_x. I’m new to all this including GIT, but I believe I have the sensors_update branch in there now. Although I did have to copy in libdaisy from my original oopsy install as this seems to not be there when I paste in the sensors_update stuff


gen~: exported: C:/Users/ted/OneDrive/Documents/Max 8/Experiment/Tring.json
gen~: exported: C:/Users/ted/OneDrive/Documents/Max 8/Experiment/Tring.cpp
oopsy-verbose: script start “C:\Users\ted\OneDrive\Documents\Max 8\Experiment\patch_tring.json” 48kHz block48 “C:\Users\ted\OneDrive\Documents\Max 8\Experiment/Tring.cpp” boost
oopsy-verbose: stop success dictionary u727000630
oopsy-verbose: start success dictionary u087000631
oopsy-verbose: “Target patch_tring configured in path C:\Users\ted\OneDrive\Documents\Max 8\Experiment\patch_tring.json”
oopsy-verbose: “Building to C:\Program Files\Cycling '74\Max 8\resources\packages\oopsy\source\build_Tring_patch_tring”
oopsy-verbose: “Will upload from C:\Users\ted\OneDrive\Documents\Max 8\Experiment/Tring.cpp by writing to:”
oopsy-verbose: " C:\Program Files\Cycling '74\Max 8\resources\packages\oopsy\source\build_Tring_patch_tring\Tring_patch_tring.cpp"
oopsy-verbose: " C:\Program Files\Cycling '74\Max 8\resources\packages\oopsy\source\build_Tring_patch_tring\Makefile"
oopsy-verbose: " C:\Program Files\Cycling '74\Max 8\resources\packages\oopsy\source\build_Tring_patch_tring\build\Tring.bin"
oopsy-verbose: “oopsy generated code”
oopsy-verbose: “oopsy compiling…”
oopsy-verbose:
oopsy-verbose: “Tring_patch_tring.cpp: In member function ‘void App_Tring::audioCallback(oopsy::GenDaisy&, daisy::AudioHandle::InputBuffer, daisy::AudioHandle::OutputBuffer, size_t)’:”
oopsy-verbose: “Tring_patch_tring.cpp:262:32: error: ‘class daisy::patch_sm::DaisyPatchSM’ has no member named ‘gate_out_x’; did you mean ‘gate_out_1’?”
oopsy-verbose: " 262 | dsy_gpio_write(&hardware.som.gate_out_x, gate_out_x); // set out"
oopsy-verbose: " | ^~"
oopsy-verbose: " | gate_out_1"
oopsy-verbose: “build failed Error: Command failed: arm-none-eabi-g++ -c -mcpu=cortex-m7 -mthumb -mfpu=fpv5-d16 -mfloat-abi=hard -DUSE_HAL_DRIVER -DSTM32H750xx -DHSE_VALUE=16000000 -DCORE_CM7 -DSTM32H750IB -DARM_MATH_CM7 -DUSE_FULL_LL_DRIVER -include stm32h7xx.h -I…/libdaisy -I…/libdaisy/src/ -I…/libdaisy/src/sys -I…/libdaisy/src/usbd -I…/libdaisy/src/usbh -I…/libdaisy/Drivers/CMSIS/Include/ -I…/libdaisy/Drivers/CMSIS/DSP/Include -I…/libdaisy/Drivers/CMSIS/Device/ST/STM32H7xx/Include -I…/libdaisy/Drivers/STM32H7xx_HAL_Driver/Inc/ -I…/libdaisy/Middlewares/ST/STM32_USB_Device_Library/Core/Inc -I…/libdaisy/Middlewares/ST/STM32_USB_Host_Library/Core/Inc -I…/libdaisy/Middlewares/ST/STM32_USB_Host_Library/Class/MSC/Inc -I…/libdaisy/core/ -I…/libdaisy/Middlewares/Third_Party/FatFs/src -O3 -Wall -Wno-missing-attributes -fasm -fdata-sections -ffunction-sections -Wno-stringop-overflow -g -ggdb -MMD -MP -MF"build/Tring_patch_tring.d” -I"…/gen_dsp" -O3 -Wno-unused-but-set-variable -Wno-unused-parameter -Wno-unused-variable -fno-exceptions -fasm -finline -finline-functions-called-once -fshort-enums -fno-move-loop-invariants -fno-unwind-tables -Wno-register -O3 -Wno-unused-but-set-variable -Wno-unused-parameter -Wno-unused-variable -std=gnu++14 -Wa,-a,-ad,-alms=build/Tring_patch_tring.lst Tring_patch_tring.cpp -o build/Tring_patch_tring.o"
oopsy-verbose: compiling…
oopsy-verbose: “generated code”
oopsy-verbose: “oopsy build failed Error: Command failed: arm-none-eabi-g++ -c -mcpu=cortex-m7 -mthumb -mfpu=fpv5-d16 -mfloat-abi=hard -DUSE_HAL_DRIVER -DSTM32H750xx -DHSE_VALUE=16000000 -DCORE_CM7 -DSTM32H750IB -DARM_MATH_CM7 -DUSE_FULL_LL_DRIVER -include stm32h7xx.h -I…/libdaisy -I…/libdaisy/src/ -I…/libdaisy/src/sys -I…/libdaisy/src/usbd -I…/libdaisy/src/usbh -I…/libdaisy/Drivers/CMSIS/Include/ -I…/libdaisy/Drivers/CMSIS/DSP/Include -I…/libdaisy/Drivers/CMSIS/Device/ST/STM32H7xx/Include -I…/libdaisy/Drivers/STM32H7xx_HAL_Driver/Inc/ -I…/libdaisy/Middlewares/ST/STM32_USB_Device_Library/Core/Inc -I…/libdaisy/Middlewares/ST/STM32_USB_Host_Library/Core/Inc -I…/libdaisy/Middlewares/ST/STM32_USB_Host_Library/Class/MSC/Inc -I…/libdaisy/core/ -I…/libdaisy/Middlewares/Third_Party/FatFs/src -O3 -Wall -Wno-missing-attributes -fasm -fdata-sections -ffunction-sections -Wno-stringop-overflow -g -ggdb -MMD -MP -MF"build/Tring_patch_tring.d” -I"…/gen_dsp" -O3 -Wno-unused-but-set-variable -Wno-unused-parameter -Wno-unused-variable -fno-exceptions -fasm -finline -finline-functions-called-once -fshort-enums -fno-move-loop-invariants -fno-unwind-tables -Wno-register -O3 -Wno-unused-but-set-variable -Wno-unused-parameter -Wno-unused-variable -std=gnu++14 -Wa,-a,-ad,-alms=build/Tring_patch_tring.lst Tring_patch_tring.cpp -o build/Tring_patch_tring.o"
oopsy-verbose: “Tring_patch_tring.cpp: In member function ‘void App_Tring::audioCallback(oopsy::GenDaisy&, daisy::AudioHandle::InputBuffer, daisy::AudioHandle::OutputBuffer, size_t)’:”
oopsy-verbose: “Tring_patch_tring.cpp:262:32: error: ‘class daisy::patch_sm::DaisyPatchSM’ has no member named ‘gate_out_x’; did you mean ‘gate_out_1’?”
oopsy-verbose: " 262 | dsy_gpio_write(&hardware.som.gate_out_x, gate_out_x); // set out"
oopsy-verbose: " | ^
~"
oopsy-verbose: " | gate_out_1"
oopsy-verbose:
oopsy-verbose: " at checkExecSyncError (node:child_process:826:11)"
oopsy-verbose: " at execSync (node:child_process:900:15)"
oopsy-verbose: " at C:\Program Files\Cycling '74\Max 8\resources\packages\oopsy\source\oopsy.js:700:6"
oopsy-verbose: " at Array.forEach ()"
oopsy-verbose: " at run (C:\Program Files\Cycling '74\Max 8\resources\packages\oopsy\source\oopsy.js:697:14)"
oopsy-verbose: " at Object. (C:\Program Files\Cycling '74\Max 8\resources\packages\oopsy\javascript\oopsy.node4max.js:31:2)"
oopsy-verbose: " at Module._compile (node:internal/modules/cjs/loader:1101:14)"
oopsy-verbose: " at Object.Module._extensions…js (node:internal/modules/cjs/loader:1153:10)"
oopsy-verbose: " at Module.load (node:internal/modules/cjs/loader:981:32)"
oopsy-verbose: " at Object.Module._load (node:internal/modules/cjs/loader:822:12) {"
oopsy-verbose: " status: 1,"
oopsy-verbose: " signal: null,"
oopsy-verbose: " output: ["
oopsy-verbose: " null,"
oopsy-verbose: " ,"
oopsy-verbose: " <Buffer 54 72 69 6e 67 5f 70 61 74 63 68 5f 74 72 69 6e 67 2e 63 70 70 3a 20 49 6e 20 6d 65 6d 62 65 72 20 66 75 6e 63 74 69 6f 6e 20 27 76 6f 69 64 20 41 70 … 429 more bytes>"
oopsy-verbose: " ],"
oopsy-verbose: " pid: 5172,"
oopsy-verbose: " stdout: ,"
oopsy-verbose: " stderr: <Buffer 54 72 69 6e 67 5f 70 61 74 63 68 5f 74 72 69 6e 67 2e 63 70 70 3a 20 49 6e 20 6d 65 6d 62 65 72 20 66 75 6e 63 74 69 6f 6e 20 27 76 6f 69 64 20 41 70 … 429 more bytes>"
oopsy-verbose: }

Hi, Just thought I would narrow down the scope of the error message in my previous post since it hasn’t been something the forum could help me with thus far. Alas, I also appreciate that there may not be anyone out there who can help due to my inexperience and therefore the possibilty that Im introducing a strange user error. What Ive done is altered the json for a patch init, with what I considered to be the most minimal of changes. I switched the name of gate_out_1 to gate_out_x in the json and then obviously used gate_out_x in my max patch. Then as you can see below, the error message is saying no to the new name. I’m not a github seasoned user, but basically I copied the recommended sensors update branch into my max packages folder . I then renamed the folder to just “oopsy” as that seemed appropriate. It then seemed I had to copy some lib daisy element in there which I took from my original oopsy download as that wasnt in the sensors update branch zip. Having got to this point it seems as below my json update is not being accepted when trying to compile.

quote=“teddexter, post:8, topic:2435”]
psy-verbose: “Tring_patch_tring.cpp:262:32: error: ‘class daisy::patch_sm::DaisyPatchSM’ has no member named ‘gate_out_x’; did you mean ‘gate_out_1’?”
oopsy-verbose: " 262 |
[/q

If anyone has an idea where I’m going wong here give me a shout.

I managed to get an LED flashing today with some edits to the patch sm related files in libdaisy. and by using a gate out. I wonder if I’m picking up the wrong resources somehow, but anyway it works now as far as I can tell, so I think I have what I need.

I get the feeling maybe the seed is further on in terms of implementation for custom pins than the patch_sm? If anybody needs more details let me know. Or if you know why I’m an idiot and how I can do it all in just the json, I’d love to know that also :slight_smile:

Just to clarify, @teddexter’s problem has been resolved (turned out to be a bug) as noted in this thread.

Nice to meet you, I’m a new member.
I built a daisy development board for the development of my module. Most of it is working well, but there is an error about gateOuts.
According to this wiki page, to define a gateout with a custom json, just write

"gtout1": { "component": "GateOut", "pin": 19 }

However, if I add this to json, I get a compile error. I tried with different pin numbers and it did not change.
I searched for this Slack and forum but could not find it. Does anyone know how to solve this?

Hi , Are you using patchsm? I ran into some difficulty with this and found a work around for my problem so it could be that youve hit the same snag as me.

Hi, I’m using the original pcb that I made so that all functions are available.
But can you tell us how you got around the problem?

Hey @kmtksk! This problem is resolved on the dev branch of Oopsy, which should hopefully see a release soon. If you or anyone is encountering this problem still, it might be worth switching over to the dev branch for now.

2 Likes

Hi, @Corvus_Prudens. Thank you for updating!

When compiling using oopsy, a compile error appears after the generated code.
After trying various methods, I found that there are various ways to avoid this problem, such as reducing the number of "out"s, writing part of the codebox process without using codebox, and so on.
Since oopsy cannot see the contents of the error, when the output cpp file is recompiled with VSCode, the following error is output.

collect2: error: ld returned 1 exit status
make: *** [build/xxx.elf] Error 1

I know this is a very complicated issue, but if there is a clear way around it, please let me know.
My own guess is that it is an i2c or led part issue.