Patches don't compile

OWL
#1

Momentarily the server doesn’t seem to compile pure data patches.

Message from stdout: “Building patch Harmonic Sweep
INFO: make exit code is 2.”

Message from stderr: “Traceback (most recent call last):
File “./Tools/Heavy/uploader.py”, line 331, in <module>
main()
File “./Tools/Heavy/uploader.py”, line 173, in main
verify=False if args.noverify else True)
File “/usr/local/lib/python2.7/dist-packages/requests/api.py”, line 94, in post
return request(‘post’, url, data=data, json=json, **kwargs)
File “/usr/local/lib/python2.7/dist-packages/requests/api.py”, line 49, in request
return session.request(method=method, url=url, **kwargs)
File “/usr/local/lib/python2.7/dist-packages/requests/sessions.py”, line 457, in request
resp = self.send(prep, **send_kwargs)
File “/usr/local/lib/python2.7/dist-packages/requests/sessions.py”, line 569, in send
r = adapter.send(request, **kwargs)
File “/usr/local/lib/python2.7/dist-packages/requests/adapters.py”, line 407, in send
raise ConnectionError(err, request=request)
requests.exceptions.ConnectionError: (‘Connection aborted.’, BadStatusLine(”’’",))
make[1]: *** [/tmp/owl-build-HMMrWH/Source/Heavy_owl.h] Error 1
make: *** [heavy] Error 2
ERROR: Patch build failed."

The patch i tried is one, that was already compiled before. I did this to check after i had tried compiling a new one i uploaded.

Just to let you know.

#2

Now it is compiling my old patch (the one above) - a newer one though gives me this from stderr:

“/opt/OwlProgram.online/Tools/gcc-arm-none-eabi-5_2-2015q4/bin/…/lib/gcc/arm-none-eabi/5.2.1/…/…/…/…/arm-none-eabi/bin/ld: /tmp/owl-build-XVBuTn/patch.elf section .text’ will not fit in regionPATCHRAM’
/opt/OwlProgram.online/Tools/gcc-arm-none-eabi-5_2-2015q4/bin/…/lib/gcc/arm-none-eabi/5.2.1/…/…/…/…/arm-none-eabi/bin/ld: region `PATCHRAM’ overflowed by 11272 bytes
collect2: error: ld returned 1 exit status
make[1]: *** [/tmp/owl-build-XVBuTn/patch.elf] Error 1
make: *** [patch] Error 2
ERROR: Patch build failed.”

PATCHRAM overflowed. Is that my mistake? Patch contains too many objects?

#3

More info.
When recompiling patches i had successfully compiled before i now run into similar “PATCHRAM overflowed” errors, that didn’t occur before. Was there server changes necessary for firmware v12 maybe? Can’t see an obvious connection between these things.

#4

It’s working now


Total request time: 1126ms
Heavy release: 1
Built sysex Harmonic Sweep in /tmp/owl-build-OXQ2Pz/patch.syx
INFO: make exit code is 0.
INFO: Build successful!

Maybe the Enzien Audio service was down momentarily.

#5

… catching up on the messages now - sorry! -

It is possible that some things require more memory now than in the previous release, since there were quite a few changes made and it’s sometimes difficult to predict how it will impact different build scenarios.

Most of the changes should have improved Pd performance and reduced the footprint (e.g. replacing all sprintf function calls), not made it worse.

It’s probably possible to make some simple improvements if we can pinpoint the problem.
Have you got a link to a patch that used to compile that no longer fits in PATCHRAM?

#6

Made this one public for testing: https://hoxtonowl.com/patch-library/patch/Rhythmizer/

Thank you for looking into this.

#7

Seems the enzien compiler is having problems again. Why to server problems always happen on the weekend?
Thanks for the patch link, I’ll check this out tomorrow.
If you use the offline tools (OwlProgram) you can try changing the opimisation level from -O2 to -O1, it can reduce the size by quite a bit.

#8

Compiling the patch with make size reveals (in cryptic hex) what the biggest objects are:


2001e138 00000318 t two_over_pi
20016fa8 00000354 T cBinop_perform_op.lto_priv.61
2001a940 00000354 T powf
2001e550 00000428 d impure_data
2001b93c 000005fc T __ieee754_powf
2001c370 00000626 T __kernel_rem_pio2f
2000c084 00000688 T main
2001d574 00000804 T sinTable_f32
20010fd4 00000a54 T hv_owl_process
2000c7f4 00001078 T hv_owl_new_with_options.constprop.18
   text	   data	    bss	    dec	    hex	filename
  74920	   1252	   2404	  78576	  132f0	./Build/patch.elf

The two biggest objects (hv_owl_…) are the contructors and block process functions generated from your code by Heavy - this is to be expected.

In third place is sinTable_f32 which is from the CMSIS DSP library, that gives us very fast sin() and cos(). Further up are functions related to powf().

We’ve got code to replace the rather slow and bulky powf functions with optimised versions, but we haven’t done so yet because it involves compiling in another lookup table, which would further reduce the available space.

However here’s some good news: I’m currently working on firmware changes which frees up part of the flash memory for storing things like the sin and pow tables. This should mean two things: much faster exponentials, and more memory (apprx 4kB in this example) available for patch code!

Also it will give us somewhere to store samples and other goodies, which should be fun!

#9

Thank you, Martin. I guess running 5 tables inside the patch just to sample from live input could be part of the problem.
(Please don’t sacrifice your weekend again!)

It simply makes me wonder, that the above patch compiled before, and now it doesn’t, and as well it was running on the OWL (if on 70% cpu or so)…