Multiapp with gen and oopsy// compiler error (also with the Max8/oopsy example)

[rob_scape]

Hi all,

i have great fun with the Daisy Bluemchen and Max Gen.

I have a couple of gen patches that all flash fine to the Daisy individually, but now I tried to flash them as a Multiapp with no luck, i get a „compiler error“.

Since I thought this was due to something inside my own gen patches I took a step back and
tried to flash the Multi-app example that comes with the Max oopsy examples.

Max8/Packages/oopsy/examples/multi_app.maxpat

But also with this example flashing results in „compiler error“
I would assume that the example patch within the oopsy example folder should work fine and the error is something on my end?

Can someone verify that they are able to flash the oopsy Multiapp example from the Max8 oopsy example folder?

Id be happy for any hints or advice why I cant flash the Max8 Multi-app example.
All the best, rob

P.s.: Im using Max 8.2.1 on Mac M1 Pro, os Monterey

[rob_scape]

I get this when I try to flash the Max8 Multi App example

oopsy-verbose: oopsy generated code
oopsy-verbose: oopsy compiling…
oopsy-verbose: compiling…
oopsy-verbose: generated code
oopsy-verbose: oopsy compiler error
oopsy-verbose: Error: Command failed: export PATH=$PATH:/opt/homebrew/bin && make clean && make
oopsy-verbose: /Applications/ARM/bin/…/lib/gcc/arm-none-eabi/10.3.1/…/…/…/…/arm-none-eabi/bin/ld: build/crossover_dattoro_gigaverb_modfm_scatter_squine.elf section .text' will not fit in region FLASH’
oopsy-verbose: /Applications/ARM/bin/…/lib/gcc/arm-none-eabi/10.3.1/…/…/…/…/arm-none-eabi/bin/ld: region FLASH' overflowed by 5656 bytes oopsy-verbose: collect2: error: ld returned 1 exit status oopsy-verbose: make: *** [build/crossover_dattoro_gigaverb_modfm_scatter_squine.elf] Error 1 oopsy-verbose: oopsy-verbose: at ChildProcess.exithandler (node:child_process:397:12) oopsy-verbose: at ChildProcess.emit (node:events:394:28) oopsy-verbose: at maybeClose (node:internal/child_process:1067:16) oopsy-verbose: at Process.ChildProcess._handle.onexit (node:internal/child_process:301:5) { oopsy-verbose: killed: false, oopsy-verbose: code: 2, oopsy-verbose: signal: null, oopsy-verbose: cmd: 'export PATH=$PATH:/opt/homebrew/bin && make clean && make' oopsy-verbose: } oopsy-verbose: /Applications/ARM/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: build/crossover_dattoro_gigaverb_modfm_scatter_squine.elf section .text’ will not fit in region FLASH' oopsy-verbose: /Applications/ARM/bin/../lib/gcc/arm-none-eabi/10.3.1/../../../../arm-none-eabi/bin/ld: region FLASH’ overflowed by 5656 bytes
oopsy-verbose: collect2: error: ld returned 1 exit status
oopsy-verbose: make: *** [build/crossover_dattoro_gigaverb_modfm_scatter_squine.elf] Error 1
oopsy-verbose:
oopsy-verbose: compiler error

[Takumi_Ogata]

Hi Rob!
I’m glad that you’re having fun with Daisy so far!

The main error is the FLASH' overflowed by 5656 bytes. This indicates that flashing failed because the total size of all those patches combined exceeded Daisy’s internal FLASH memory, which is 128kB.
I recommend removing one of those patches and trying it again.

If you think that you’ll exceed 128kB in your actual project as well, I suggest giving Bootloader a try. This is a new feature in the upcoming Oopsy update (there is a pre-release that you can try out now though!).

[rob_scape]

Ok. Thanks so much. I was expecting it was overflowing the internal FLASH, but then again i was really confused, since the example is inside the Oopsy example folder and I think I saw a YouTube Video where Graham Wakefield is flashing that exact Multi App patch from the Oopsy examples, so I suspected there is some wizardry that I am missing.
I made another Multi App test with 6 gen patches each containing just six cycle objects and these flash fine as Multi App. Bootloader sounds fantastic, I’m definitely very excited about these Oopsy updates. Thanks so much!

[ArguZ]

Hey rob,

the problem is the hardware in Bluemchen.
oopsy uses a lot of memory to address that one.
Look at this…
That is my multi effect compilation flashed to Petal

And here the same set compiled for Bluemchen

Almost 28000 bytes extra…does not compute.

Bluemchen alone with an empty GEN~ container … 75% of memory gone…

Boy, i really hope we can get into that bootloader business soon

[rob_scape]

Oh wow, thanks so much. That is super interesting.

I have a bluemchen (that I love very much) but also a bare Daisy Seed. I set it up on Breadboard with encoders, screen etc. exactly like the bluemchen, so I can do test flashes easily before moving it in my modular. It never occurred to me to set it up differently on Breadboard, but after seeing your screenshots I might give it a try to do a setup on breadboard just like the Petal. So thanks for sharing your screenshots!

But yes, bootloader will be so cool!

[tele_player]

Can you explain what exactly is the problem with bluemchen hardware?

[Takumi_Ogata]

The “problem” in context of this thread is that a program that barely fit in Petal overflowed for Bluemchen.

[tele_player]

Yes, but @ArguZ wrote that the increased memory usage was caused by Bluemchen hardware. So, what about the bluemchen hardware uses more memory? If it’s the display, build the app without the display code.

[Takumi_Ogata]

This!

To @ArguZ and @rob_scape :
This whole thread comes down to the matter of needing to cut down on certain gen~ patch depending on your hardware configuration.
The multi_app program built for Daisy patch.Init() is around 78KB, but the size becomes larger than 128KB when built for Daisy Patch (which has more required code for configuring OLED, encoder, and etc).

I should’ve added this in the original response.

[rob_scape]

Yes, I took that from the screenshots that providing “infrastructure” for the OLED, encoder etc. requires more code. Right now this is no problem at all, i flash my patches individually to make sure they work as expected. If I’m brave enough I give the prerelease a go to test Bootloader.
The thread has been really helpful, so thanks for all your answers.