electro-smith / oopsy Goto Github PK

The values of the params in the gen~ patcher may not be effective names for a useable control interface.
In order to improve the building of custom UIs on Daisy hardware I propose the ability to add a string at the end of the param name that signifies what shall be displayed instead of the values that are used. I think this particularly makes sense with int or bool parameters that are used for switching modes/settings in gen~ . Since we can only do it in the param name itself your idea from slack sounds good:

[param knob1_mode_stereo|pingpong|ms @min 0 @max 2]

I case you end up implementing this it would be perfect, if the param name that gets displayed ignored those value settings (as well as the int/bool setting) to clean up the interface.

Hi there!

I'd like to be able to control params in a gen~ patch loaded onto the Daisy Seed from a secondary microcontroller (ESP32) over either UART Serial, I2C, or SPI. Would it be possible to modify the same process of setting custom pins for external control through pots and buttons in order to receive data coming from these busses instead?

The request is for some parameters to be forced to integer values, e.g.

[param cv1_int_mode 1 @min 0 @max 8] 
[param cv2_int_enable 1 @min 0 @max 1] 
etc

Per request on https://forum.electro-smith.com/t/meet-oopsy-daisy-object-for-max-msp-gen/944/32

https://github.com/electro-smith/libDaisy/tree/master/src/ui provides a set of generalized UI features for OLED displays. It would be great to migrate oopsy interface to use this, and to provide more flexibility for users to define new UI interfaces as an alternative the standard default Oopsy currently generates.

Biggest challenge is figuring out how to specify such interfaces; it seems a bit more than what can be jammed into param labels etc. Probably some kind of JSON structure needed.

An update on the dev branch appears to have left the OLED encoder non-functional on the Daisy Patch (possibly also Field?). There have been a lot of updates recently including an update to libdaisy, which may be a cause?

Investigate and remedy.

This one has been on the roadmap for a while but wasn't documented yet:

Rather than using e.g. [out N cv1], [out N midi_cc1] etc., we could use [history cv1_out], [history midi_cc1_out] etc., which the oopsy cpp snooper can detect and generate the required code for. (The postfix of "_out" is necessary because gen~ code generation can rename variables if they end in a number.) This might be a bit less confusing, and certainly should be more efficient than using [out]s.

Will need relevant source files from CMSIS/DSP/ added to Makefile, and verification that all the various math definitions are implemented, and then measure CPU/memory tradeoff.

Hello! I have some troubles with loading examples on my daisy patch from max on windows machine.
I'll write down the entire sequence of actions:

First, I installed all the necessary toolchain on my machine, as it was written in the instructions in daisyWiki. I added all the necessary paths to my PATH environment variable. Next I cloned oopsy repo from github and I tried to run the install.sh And I got error:

Then I opened the script and executed the commands line by line. But the make file was always running with an error 127:

335 line in makefile:

I checked the contents of the build folder and a large number of files appeared there.

Then I decided to try to run the project from the example. Opened the reverb.maxpat patch. I put Daisy in boot loader mode, made sure that the computer sees DFU in FS Mode.

Then I clicked on the bang and everything seemed to run without errors, but the loading into the module did not occur. There are no warnings or errors. Just nothing.

The firmware files appeared on the disk

From web browser all works correctly. I tried many examples from your site and they all loaded and worked.
I really hope that you will help me quickly solve this problem, as I planned to use the module soon. Thanks!

Here I am, LLT, following our discussions on the C74 forum. you will find attached the patch

----------begin_max5_patcher----------
2348.3oc4bs0aiaiE94L.y+AA+XQFGQRcsOMK1tEnO0Aam8ghhBCZKZGNQVT
PjNWZwt+1WJRIqKVVhxMxNN8gDYQRIcNemq7HJ9me7C2LaI6YBel02a8aV2b
yeJa4FUa4sbSYC2LaK94UwXtZfyVw1tkjHlcaQmBxyBUGekrMMFKHVqYYV+.
lxe4Goj3n8CbMKQjf2RTC9ejQwwV+j.GSWseDzHUerke6SPm8slhEqtmlrYQ
FYkPSqPm412ZAg5+CTG7maa86kWSxtszjXhPQxf5T.m9GJJ.DHuppQy1IJGt
sp0+6G+P9Q4gaMFZH+QDd0+qK1AfFlcbbBTGbK++QXG3qMYGSejLeCllTQ5O
hy1Kp5n6TblrWAIaAIAuLlz.k0zj3kThl6lwoaRvwyts9ux+acLCKx+QLkKQ
h8bqjvjPDNIgDuhsKQAR1cApfgAUjCTis4+OzdrfpaYyb7ijnEXgHitbmfT8
KdAxVBs4XW7NBacY666nNrEyR1zC.2XrakBq7w4sWgsU2zj7t+juc2CfeOKS
X5CqTr04cZWBUvEunk2NECnPiq5GmhJ3Rk.jjUo.RIO8HkSWRiohWZpesdMm
THjyYYqFR0X1pGHQQY3M7UYr33FJOqjdadPbeFa2l6azgVM99NtDcOO1QOK2
rkEQZ1DKKRxD0a5XVC0zCKEMQjsLtTgOZtDaRwUtXwYaJbRO6ywLVpzlAHMa
97ZpTTH+w2jZSwuLGSWW61VyPweX6DWWsuT0Af8w89bDmlfSVzmPdRRic544
G+2+zW9hzVIleXzlMjZ9iF1kSm3hANkggJULPn1ah2vNPpGjQcO5DufMdxZc
lFdQxksORx3TVRcseoxPZZs1a4gYK9aL08Jnx9URj51.UskQxMtJt00r0wYR
XPHwfcYZQvydN07SjqvmkriVIw0B6RZSIUyEe7T7pBkZd5borZ+MYVEBCzZa
HajVoKTcpeHrFHmaloMoa3UZFKkjPSRyHbYtHXQAqT0eDYMdWrXQiP9v4cOf
0EDa281LmkJFYSFMhkjSHMEP4sW9HkLo1hxsAOoFRBNsqKWpXJQni0KWxr63
KwYJmiZOwv88JXr3l8Uckwj0hh9SoxXqs.TAKsmdynatuuqdIS161du8pt3x
XH5tWjGkeQdX0VCDGGW3Rn0S3YbBcqL+RAUKOf1U8df+aPqtdrqthjVAqHOQ
iD5nAMTOjW.MsTwZVkXOhtgvEsZTf0dnq0z9.k0aaWYftEhhrkaMBo8iLYHY
H6m3EirT8qATTkzdC6+5Naa1QuNca5YUFfg+x7Uhr347sLl3dTiwcfu1JeqG
3e0twU1kSVO+4t2ZE.0d.BJSqu4sryr4OZPnFIkrOXzqON8cmLr.FBVB03Qd
3las7bL.UfW+nBbPkEIF3dkBKpjnsV8nyBYTqchGYwVeVRmReNxi3ms.xiEA
cjs4NJPrmfTswXGCMHc0fafIXrcaZoq3sWZ7+0yoFHbHLzCflCkfnCx8Jzs1
qGRELDP45YWCf9aKNgLDmtNiRJIXa6S1XyTUHcLAGz0Dzb5nxfVV.eeMRnsr
BGqa72BgJAKhheYAmrhkDwKiVZCzwKQvZALAdymn.lPeCU.0.MBF9dIfYJg7
fUdwlnIDN2BZ84hRxlWC.qmxvoC.4EE48zyUYP2hN1pJ+ib0fti6XSHzbrGc
Vw96kSAjk8xo5d.NXFJ.j9MNXq7R33cM40bULM05S.KvICOdCpXEBTIAqeAS
tn+dAOCgNH+fqVzYK84SNnqsg.iienwyOE8N.XL0b5pDW9NUNGSU1ECFhCY6
TyVyANVas2pYWHG01zoBUMdRCEkYyCM22cbpjuUw0sxDG3RnkOUXqsoXq1L2
+ciFaJ6ARs7gapiYN.B7MrJmt9N5Y6CFq6RyQP6KIBZepHnmYUO+8G.FgE3Z
.nSfsssEzfogcpV6.2gfZeY7I+pZxCPnoa9uvyJXOUw7ANFN4rSt1MuYi4mu
VtpVhOSTYC.HSwWWu8q0kox+v4srAxGbK2Ai.1flNoXsaUj+zEX29hTtQTd4
FkSC5R7d4..iemR5R1.88d2TnwB7GpJ2aFYCIoPDnk.ggyCqjA9SkHHzvohU
H.P1v2KB.ITC0H9mJJt9TE6yzbeg5EDFz8cDDCNOPrqYIG+tCgyi8cpyIywz
Jdd4B8UasCFmm8+QV8WJZOe.GAN4rcYqJ0wJ75Y0hMhHbAMY+Rp72pJUU9HM
WnNZZIvTZAL4jhuojR9hVZhoEOiEQdSNs3ZLtL8xn70xjgDi8zSL4lG.SHFO
8.mZZwLCI6omXflRLcnmukFkxnIhB2cPTQ8ZUSL1UWXG0YMurpOBi2DLFnCu
I6IQvTRh.iIQu29jn8f5G4k5KuVTApJPiBz0OIv9xneXOpXHf9070KmG.HTk
dbsydayYfQxY.GO0gd3rIUazTFKXxCn.CGk6k9AYfCRM0U8Z6E5izq5C+Kh5
yH3LuC4ryhd.z77+ldEAiy+CL84hBQiRqDdITuPiR8B1qgCBT7wQFnCrnLiT
mcIzJMOVIZPNy0SGJAob3BgUmMsJPFG6.N8yfv3L3blbRADNlzj6Wz5Agp2I
mS4mxg2kzcu4blJCuQwZNnAijMkFjffQYPNsSzB3NJKK3zRLNiBYlXaKiiHz
0Lm6NUJj9CjxAXu+rKgskwbVWIccdrQLOnU3zqIXdzmomVLlT5u5UkcT8Y3W
rWkn+Nx6aiJg7bJKSrlEWnGL6e9828e3jL9cw3cYj69AB+AAK8te9m+xu7qK
95+5W95cUenx5Ktqspg+56FH4z7N5w2cGpsaNjOT8pKn42KRm6oP8tcOnWvZ
AEqVnCWGKGYOE50Zav3z34Zuzzt3XGC33hE.Av095fkKeO8cwud8yugZFELO
.F35CbT+GE5bEw8Ue+vcw+Alv+9Ny8KY97+6bY3+2ua4O6cJp+DQ6Yy7QHOg
n1BrVq1pz5bWpIrOgpaQR95pnUrjwfAiUL1dyCSe0MeWiEh01Q5JEtC7Rz5o
.JUk3ocZScpWYLADXJATFc8u1iyeDOtC3Wvq.A3cd4Wmy6iCYxiC.d0ddvyK
60JQYSltzqvCDXzCDbvCrv+Pq8hJ0yp8dPU68ept16o5Yem5f8bphDc6ZulJ
OhyG+fb.+e3DZDtM
-----------end_max5_patcher-----------

May require some larger changes to genlib_daisy.h, a custom target JSON, etc.

Also documentation of how to do it!

If the device has OLED it could be used to tweak param values that were not mapped to hardware inputs. E.g. Patch has only 4 CV ins, but a gen~ patch might have 8 params. The extra 4 unmapped params could be available on an OLED page for manipulation with the encoder.

Options to choose input and output channels to display on the scope.
Option of stereo display? Option of Lissajous display?

This can cause a pretty hard to notice error:

process_begin: CreateProcess(NULL, rm  -fR build, ...) failed.
rm -fR build
make (e=2): The system cannot find the file specified.

If git-bash/git-for-windows was installed, and the option for allowing *NIX-like commands within Command Prompt (cmd.exe), then this doesn't happen.

However, in systems that don't have that installed that way rm doesn't exist.

The windows equivalent is del.

I can look into adding some platform-checking to the Makefile, but it might be worth just trying to replace the:

console.log(execSync("make clean", { cwd: build_path }).toString())

call with:

console.log(execSync("del build", { cwd: build_path }).toString())

That said, this is not a good solution if make clean ever does anything more sophisticated than just delete the build folder..

lines 145-148 of oopsy.js

if (hardware.max_apps && cpps.length > hardware.max_apps) {
     console.log(`this target does not support more than ${hardwre.max_apps} apps`)
     cpps.length = hardware.max_apps
}

hardwre should be hardware

I didn't check if this is resolved on dev or not yet, but figured better to put it somewhere than forget about it before I check.

I thought it was a hardware problem, but it turned out not to be. I uploaded a logic example for patch from a web programmer and there the outputs work independently.
In oopsy I just connect knobs to CV outputs:

param ctrl1_test1 → out 5 cv1
param ctrl2_test2 → out 6 cv2

IO modes, e.g.:

in1:out1, in2:out2, etc.

Also additiional channels on Patch, e.g.

in3:in4, out3:out4, in3:out3, in4:out4 etc.

On my protoboard, the 4-bit mode does not work

So I use the 1-bit mode when working on C++ (which works at any speed)

Is it possible to use the 1-bit mode on Oopsy?

/** Sets whether 4-bit mode or 1-bit mode is used for the SDMMC */

enum class BusWidth

{
    BITS_1, /**< Only 1 bit of data per clock is transferred */

    BITS_4, /**< 4-bits of parallel data for each clock pulse */

};

Hi,
I have installed all the toolchain components on MacOS Big Sur verified by successfully running the following:

make --version
arm-none-eabi-gcc --version
dfu-util --version
openocd --version

When pushing a gen patch (reverb example) to the daisy pod from Max 8 the console outputs:

oopsy-verbose: /bin/sh: arm-none-eabi-gcc: command not found
oopsy-verbose: make: *** [build/system_stm32h7xx.o] Error 127
oopsy-verbose: make failed

The daisy web programmer works as expected and running the same process on my aging 2013 macbook air worked OS 10.13.6

Are there some different install methods required for Mac OS Big Sur?
Of note when I open a terminal on my old computer and navigate to ../usr/local I can see Homebrew and Caskroom and many other folders. On my new computer when I navigate to ../usr/local it is empty.

Pls let me know what i should try,
thanks,
Adrian

Hello since I installed the last correction of the dev version, I no longer have midi in out in the Daisy Patch.
And the params are no longer visible in the OLED screen.
I am using windows 10 and Max 8.1.10

For the midi did a simple thing [in 5 midi] in [out 5 midi] to pass the midi information in my other devices and it worked very well.
I must be missing something in a new midi param syntax

LLT

Data objects could load audio data from wave, other binary, or even text files stored on SDcard if the names match.

Per thread here: https://forum.electro-smith.com/t/is-there-an-nprn-encode-decode-supported-by-default/1669

Some notes from the thread:

• NPRN Type are the CCs: 99 (MSB) and CC 98 (LSB), as you noted above
• NPRN Data/Value are the CCs of: 6 (course/MSB) and 38 (fine/LSB) for the values.
• https://en.wikipedia.org/wiki/NRPN
• https://www.elektronauts.com/t/nrpn-tutorial-how-to/46669
• https://cycling74.com/forums/how-do-i-nrpn There are "nrpnin" and "nrpnout" objects in vanilla Max.

Seems like this could be prototyped using existing CC handlers in oopsy, and a bit of math for the MSB/LSB handling, and some logic for the possibly sequential nature.

If it seems solid and workable, it should be feasible to create e.g. param midi_nrpn_XYZ and history midi_nrpn_XYZ_out etc., where XYZ refers to the NRPN type.

I note that I've seen some quite inconsistent and strange uses of NRPN by different hardware, so I'm a bit hesitant to push for something that might be an endless series of cases that don't work... but I admit I've never really dealt with them so maybe there is a generalized and flexible pattern that can be used.

On my machine, the main oopsy branch works as expected and I am able to flash Gen patches to my daisy patch. However, when I attempt to use the dev branch, the Bpatcher generates a "compiler error" message and the patch is not flashed to the daisy.

Log:

gen~: exported: Macintosh HD:/Users/simon_ho/Documents/Max 8/Packages/oopsy/examples/crossover.cpp
oopsy-verbose: script start patch 48kHz block48 /Users/simon_ho/Documents/Max 8/Packages/oopsy/examples/crossover.cpp boost
oopsy-verbose: stop success dictionary u296001129
oopsy-verbose: start success dictionary u184001130
oopsy-verbose: using build tools found in /usr/local/bin
oopsy-verbose: Target patch configured in path /Users/simon_ho/Documents/Max 8/Packages/oopsy/source/daisy.patch.json
oopsy-verbose: Building to /Users/simon_ho/Documents/Max 8/Packages/oopsy/source/build_crossover_patch
oopsy-verbose: Will upload from /Users/simon_ho/Documents/Max 8/Packages/oopsy/examples/crossover.cpp by writing to:
oopsy-verbose: /Users/simon_ho/Documents/Max 8/Packages/oopsy/source/build_crossover_patch/crossover_patch.cpp
oopsy-verbose: /Users/simon_ho/Documents/Max 8/Packages/oopsy/source/build_crossover_patch/Makefile
oopsy-verbose: /Users/simon_ho/Documents/Max 8/Packages/oopsy/source/build_crossover_patch/build/crossover.bin
oopsy-verbose: oopsy generated code
oopsy-verbose: generated code
oopsy-verbose: compiling...
oopsy-verbose: oopsy compiling...
oopsy-verbose: oopsy compiler error
oopsy-verbose: compiler error
oopsy-verbose: null
oopsy-verbose: In function 'gen_numname',
oopsy-verbose: inlined from 'dir_register' at ../libdaisy/Middlewares/Third_Party/FatFs/src/ff.c:2339:4:
oopsy-verbose: ../libdaisy/Middlewares/Third_Party/FatFs/src/ff.c:1825:8: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
oopsy-verbose: 1825 | ns[i] = '';
oopsy-verbose: | ~~~~~~^~~~~
oopsy-verbose: ../libdaisy/Middlewares/Third_Party/FatFs/src/ff.c: In function 'dir_register':
oopsy-verbose: ../libdaisy/Middlewares/Third_Party/FatFs/src/ff.c:1796:7: note: at offset -1 to object 'ns' with size 8 declared here
oopsy-verbose: 1796 | BYTE ns[8], c;
oopsy-verbose: | ^
oopsy-verbose:

Hello,
So happy to be a new oopsy daisypatch user!
But i'm struggling to send some NoteOn/Off with the "oopsy.midi.format" abs ...
Could be very useful to extend the "midi_io.maxpat" with an example of dealing with "notetrig, notnum&notevel" datas format...
Thank you so much for these awesome tools
Mathieu

@see https://forum.electro-smith.com/t/meet-oopsy-daisy-object-for-max-msp-gen/944/18

Recognize a program-change MIDI event and have it switch apps accordingly.

On Pod currently [out led1] is hardcoded to map bipolar signal to red/green.

To address RGB channels individually I'm thinking that using a unipolar [history] would make more sense, rather than clogging with lots of outs. E.g. [history led1_red], [history led2_blue] etc.

hello, I have a problem with [in N midithru]. I don't know if I'm doing something wrong, with an [in 6 midithru] at [out 6]. When I play notes everything is normal but if I also send pitch bend or mod very quickly the midi output bug and cuts off and all the midi instruments wired to the output freeze

Handy in some cases to be able to visualize what's going on in certain algorithms using [data] objects.

Push encoder/sw1 to switch between listing [data] names (scroll to select) versus viewing data contents (scroll to zoom)?

On a Windows host the automatic build + download is not working. The soure/oopsy.js script performs a "make -n" i.s.o. a "make" (line 254).

Control-rate inputs are sampled at block rate (1ms by default), which can lead to audible warbling-stepping according to what smoothing is happening in the hardware.

It could be good to include a few subpatcher examples of different ways to smooth these (onepole, ramplimit, lowshelf, etc).

Additionally, adding the ability to use [in cv1] instead of [param cv1] etc. might be a way to automatically provide smoothed input.

Field has 24 LEDs. It doesn't make sense at all to have these use an [out] for each one. Some kind of stream multiplexing or binary coding is probably wanted here, so a single [out] can drive them all.

See electro-smith/libDaisy#247

Currently we can capture custom param names if declared after the input prefix; for example param cv1_wet will map to cv1 and we store the param label as "wet". These labels are not yet being used in the OLED but should be.

Requirements:

• libdaisy needs a ResetToBootloader function
• Class for initializing DaisySeed USB in CDC mode (VCOM port), and a short callback for receiving some sort of jump to bootloader message. (could be in libdaisy or in the code generator)
• Serial Tx from Node to the Daisy to send message for reset before running make program-dfu.

MIDI output might be simpler to manage (and possibly more efficient) if exposed in gen~ as a [data] rather than via [out].

Similar to the use of [out 5 midi_drum36] and [out 6 midi_cc1] etc., add support for [param midi_cc1], [param midi_drum36] etc.

It would be really neat if there was a mode added to the existing scope modes that enabled users to view the cv1 and cv2 outputs visually. I've experimented with connecting my cv1 output to the out1 audio output, in which case the signal is shown on the scope for out1, but it requires sacrificing one of the audio outputs and the scope parameters aren't optimal for viewing cv data.

In the same way, it would be nice to have an "output" data page that is similar to the params page, but lists all of the output data. (cv1, cv2, gate 1, midi data even).

Ideally emulating the device inputs & outputs with Max equivalents.

After the make -n -> single commands hack, the stdout is not helpful, and looks really messy.

Simple readable output like, "building", "flashing" etc. would be more ideal.

Based on Alius' feedback from working from an M1 macbook pro, it seems that homebrew installs things to /opt/homebrew rather than /usr/local

Easy enough to have oopsy.js use a different prefix path accordingly, but would require some kind of detection method.

Perhaps the smartest thing would be for oopsy.js to test for the existence of the gcc-arm-embedded binaries in likely locations, and use the path of whatever is found (by some priority such as modified date in the case of multiple hits?)

By the same method, it could test for dfu-util etc., which will likely be more helpful user feedback too!

For example [param midiclock] would be a relatively easy and very useful addition.

Could be included in the Max package as a snippet.

1. Avoiding needing to push buttons on hardware to initiate flashing
2. Having script aware of whether device is available for flashing, and flash success. (Would implementing webdfu via node.js help here?)

On my breadboard I have connected only d0 (not d1,d2,d3) to use the 1-bit mode

I downloaded the dev branch

I checked the genlib_daysi.h to be in 1-bit mode

void sdcard_init() {
			daisy::SdmmcHandler::Config sdconfig;
			sdconfig.Defaults(); // 4-bit, 50MHz
			// sdconfig.clock_powersave = false;
			// sdconfig.speed           = daisy::SdmmcHandler::Speed::FAST;
			sdconfig.width           = daisy::SdmmcHandler::BusWidth::BITS_1;
			handler.Init(sdconfig);
			dsy_fatfs_init();
			f_mount(&SDFatFS, SDPath, 1);
		}

On that folder, I opened oopsy-dev\examples\sdcard-minimal.maxpat

I copied the drumloop.wav on my SD

I run it on my daysi but does not work

I checked with C++ (WavPlayer.cpp with 1-bit mode) and it works, playing drumloop.wav on my daisy

Use of the OLED on Patch etc. doesn't occupy too much CPU but does eat quite a bit of program size -- seems like about 6k + 2k per app on a quick local test -- which might be desirable to bypass in some cases if total program memory is running out.