Patch/Load object

#5

multiple patch/load objects should work too

#6


Can't get this work. Any tips?

#7

What is the name of that object?

#8

For diagnosis I suggest to add a script/script2 object to the patches that you want to load with in the script something like this:

void setup(){
   LogTextMessage("patch x loaded");
}

void loop(){
}

and maybe modify the patch/load object:
"edit object definition" in its popup menu, and change the "K-rate code" to

if ((inlet_trig>0) && !ntrig) {
   LogTextMessage("loading patch attr_filename");
   LoadPatch("attr_filename"); 
   ntrig=1;
}
else if (!(inlet_trig>0)) ntrig=0;
#9

patch/load fn
https://raw.githubusercontent.com/axoloti/axoloti/master/objects/patch/load%20fn.axo

#10

I forgot to mention that LogTextMessage will post the string to the Axoloti log screen, this does not require a live connection to the patch.

#11

This is what I get:

Generate code complete
Start compiling patch
RM
rm -f /Users/jokischaller/Documents/axoloti/build/xpatch.o /Users/jokischaller/Documents/axoloti/build/xpatch.elf /Users/jokischaller/Documents/axoloti/build/xpatch.bin /Users/jokischaller/Documents/axoloti/build/xpatch.d /Users/jokischaller/Documents/axoloti/build/xpatch.map /Users/jokischaller/Documents/axoloti/build/xpatch.lst
APP
arm-none-eabi-g++ -nostdlib -fno-exceptions -fno-rtti -mcpu=cortex-m4 -O3 -fomit-frame-pointer -falign-functions=16 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -fsingle-precision-constant -Wunused-parameter -DCORTEX_USE_FPU=TRUE -DTHUMB_PRESENT -mno-thumb-interwork -DTHUMB_NO_INTERWORKING -mthumb -DTHUMB -std=c++11 -DARM_MATH_CM4 -D__FPU_PRESENT -H -I/Applications/Axoloti.app/Contents/Java/CMSIS/Include -I/Applications/Axoloti.app/Contents/Java/chibios/os/ports/common/ARMCMx/CMSIS/include -I/Applications/Axoloti.app/Contents/Java/chibios/os/ports/common/ARMCMx -I/Applications/Axoloti.app/Contents/Java/chibios/os/ports/GCC/ARMCMx -I/Applications/Axoloti.app/Contents/Java/chibios/os/ports/GCC/ARMCMx/STM32F4xx -I/Applications/Axoloti.app/Contents/Java/chibios/os/kernel/include -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/include -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32F4xx -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32 -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32/GPIOv2 -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32/I2Cv1 -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32/OTGv1 -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32/RTCv2 -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32/SPIv1 -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32/TIMv1 -I/Applications/Axoloti.app/Contents/Java/chibios/os/hal/platforms/STM32/USARTv1 -I/Applications/Axoloti.app/Contents/Java/chibios/boards/ST_STM32F4_DISCOVERY -I/Applications/Axoloti.app/Contents/Java/chibios/ext/fatfs/src -I/Applications/Axoloti.app/Contents/Java/firmware -Winvalid-pch -MD -MP --include /Users/jokischaller/Documents/axoloti/build/xpatch.h -c /Users/jokischaller/Documents/axoloti/build/xpatch.cpp -o /Users/jokischaller/Documents/axoloti/build/xpatch.o
! /Users/jokischaller/Documents/axoloti/build/xpatch.h.gch
/Users/jokischaller/Documents/axoloti/build/xpatch.cpp: In member function 'void rootc::instanceload__2::dsp(int32_t)':
/Users/jokischaller/Documents/axoloti/build/xpatch.cpp:67:54: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
if ((inlet_trig>0) && !ntrig) {LoadPatch("OSC.BIN"); ntrig=1;}
^
/Users/jokischaller/Documents/axoloti/build/xpatch.cpp: In member function 'void rootc::instanceload__1::dsp(int32_t)':
/Users/jokischaller/Documents/axoloti/build/xpatch.cpp:103:55: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings]
if ((inlet_trig>0) && !ntrig) {LoadPatch("OSC2.BIN"); ntrig=1;}
^
LINK
arm-none-eabi-gcc -nostartfiles -Tramlink.ld -mcpu=cortex-m4 -mfloat-abi=hard -mfpu=fpv4-sp-d16 -mthumb -mno-thumb-interwork /Users/jokischaller/Documents/axoloti/build/xpatch.o -Wl,-Map=/Users/jokischaller/Documents/axoloti/build/xpatch.map,--cref,--just-symbols=/Applications/Axoloti.app/Contents/Java/firmware/build/axoloti.elf -o /Users/jokischaller/Documents/axoloti/build/xpatch.elf
BIN
arm-none-eabi-objcopy -O binary /Users/jokischaller/Documents/axoloti/build/xpatch.elf /Users/jokischaller/Documents/axoloti/build/xpatch.bin
Done compiling patch
Start uploading patch
bin path: /Users/jokischaller/Documents/axoloti/build/xpatch.bin
block uploaded @ 0x20011000 length 3684
Done uploading patch
Start starting patch
Done starting patch
Start locking
Done locking

If I press one of the buttons it appears:
"Axoloti says: patch x loaded"

Still can't load a different second preset :frowning:

#12

You mean, after you have triggered loading the 1st?

#13

Yes. Sometimes the button of the second is also already black.

#14

To load OSC2.bin from OSC.bin you also need to have the same loading mechanism in the OSC patch.
The ctrl/button staying black, I guess that comes from the "detach" from the live session, the button should be cleared before going live or uploading, otherwise this will trigger an immediate teleport to a new patch when going live with the 1st.

Also helpful in diagnosis may be the virtual remote control (in window menu), I believe you can load a patch from sdcard through that, and this uses the same loading mechanism.

#15

Do you mean I have to place the patch/load object into the osc patch?
Can you or someone else give me an example how to proper use this object? I suppose I am doing something completely wrong... :astonished:

#16

If you want to load OSC2 from the OSC patch, yes. Likewise, if you want to load OSC from the OSC2 patch, you also need this loading mechanism in the OSC2 patch.

After triggering patch/load, Axoloti forgets the original patch.

#17

Damn. I thought the patch/load object has to be in a separate patch where the other patches are loaded into (similar to the subpatches).
I will give it a try tomorrow.
Thanks for the help Johannes!

#18

You can make a subpatch with the patch loading mechanics, and instance this subpatch in your patches, so you only have to define the loading mechanics in a single place.

Loading a patch as a subpatch dynamically is not possible.

#19

the new controller object preferences now in github will allow you to do this without having to change all your patches. (not sure when this is being released though)

#21

How does it work? Just finished a new build from github a minut ago. Would love to test it.

#22

very simple, a controller object is just a subpatch.
in preferences give the name of a subpatch you wish to use as a controller object
(and ensure its enabled... theres a checkbox so its quick to enable/disable without having to enter the object name again)

whilst enabled, this subpatch will be wired into every patch you compile (ie. go live or put on sdcard)

it can do anything you want, but of course does not have inlets/outlets (by design, as if it did you would have to wire it in)

its normal use case is to use with a (hardware) controller (doh, hence the name :wink: ) so hence intercept the midi and then do something... this could be simple like intercept program change messages and change patches, or more complex like my Push object which intercepts all midi, applies scales, looks at parameters and displays them etc.
(you don't have to do midi it could for example use GPIO encoders)

the 'limitation' of not having outlets, means you will tend to use 'internal bus' to communicate with the main patch if necessary, or drive parameters directly... the later is more 'advanced' since its only possible via the C api.
quite likely other things are possible too, and it may be later I introduce some objects which allow controller objects to be built more easily ...

but for now Ive been using it really with my Push so that I can drive patches without having to patch the push in to each patch :smile:

tip: be careful with size/resources (e.g. preset allocation etc) a controller object uses, as its applied to all your patches, so its an 'overhead'... if a patch doesnt work with it enabled, try disabling it... if it works then probably your expecting a bit much the axoloti board, so you need to simplify your controller object

enjoy
Mark

New Version 1.0.4
#23

Since the last update, this controller object has replaced the choice we had with all the midi inputs on the system (in the preference menu).
How can I now, using only axoloti on my system, choose which input device I can play to send midi information to my midi/in objects?
I can do the routing in my DAW, but I quite liked not having to load it.

#24

no, the controller object change was completely unrelated.

I coded the midi input (which was in the preferences) before Axoloti exposed itself as a class compliant midi device. it was at that time the only way to send midi from the PC/Mac to the Axoloti, as it had to go via the serial interface.

once Johannes added midi class compliance to the usb implementation, it was no longer needed for that purpose so could be removed.

we could add something similar back I suppose, it would be a bit different, since now it would make sense to go via the midi device (as should the 'onscreen keyboard') rather than as it was previously, but its not hard.

... questionable though if this is right the direction for axoloti, as its adding general midi functionality to the PC/Mac UI, rather than something that is particular to axoloti.

alternatively, there are quite a few lightweight (non-daw) products that do this... and with more control/manipulation e.g. on the mac I use midipipe, similar things exist for the PC

#25

midi-OX is quite nice on windows