Help with logic in axo

#1

Hello,

I am using a custom midi player provided by @SirSickSik here (without the EOF bit)

The player needs to receive:

1 A string with the midi file name
2 A signal in LOAD inlet
3 A signal in PLAY inlet

I made a patch that should load a different midi file every 4 minutes, but I don't know how to sequence the "load" and "play" signals right after the midi file name is sent to the custom midi player:

image.png1066x406 20.7 KB

What this patch does:

1 The bpm generator beats 60 times per minut, so once per second.
2 Every 240 seconds (4 minutes) the carry pulse output makes the second counter increase by one.
3 The output of this slow counter is used to control the index of the string muxer.
4 The output of the muxer is sent to the custom midi player string in.

... now, as far as I understand, "load" should get a signal, then "play". And as this is going to be continuous (and Axo is not event driven) I think the signals should be ON all the time, and when the string midi name is received go OFF, then ON again.

Is that correct?

How can I do that?

Thank you very much

#2

try rbrt/control/trigger 2 for the sequential switching on of load then play, then a flip/flop toggle with a delayed pulse like below, should get you there...if not come back and we'll try again

toggle sequence.png868x339 18.4 KB

the Bools and the button are for illustration only, you would of course integrate the triggers and the switches into your existing patch....but this set of objects will illustrate what's going on, and of course you can determine the best working delay for the the sequential trigger and the delayed pulses for your needs, ie is there to be a pause in play of the midi file

#3

Looking at it right now,

I have a question tho. If all this needs to happen after the string with the midi filename is sent from the muxer to the custom midi player in my pacth above... shouldn't that be what starts this chain ?

If I am right, how should I convert such string signal change into something that triggers this chain ?

Thank you

ps I am sending you a pm regarding something else that may be of interest.

#4

Try this

sequential load.png1141x481 52.1 KB

this object loads 16 files, do you need more?sequential load.axp (12.0 KB)

#5

This one will allow the 20 strings that you need

sequential load B.axp (13.1 KB)

#6

Thank you very much @reubenfinger

Although the patch (16x version) seems to work well 'standalone', when pasted in the actual synthesizer patcher that should receive the midi messages, it fails to either go live or flash to sd with the following message:

Generate code complete
Creating directory on sdcard : /sequential load
Done creating directory
Changing working directory on sdcard : /sequential load
Done changing working directory
Start compiling patch
Compiling patch... with /opt/Axoloti/app/firmware
BDIR = /home/jaume/axoloti/build
FIRMWARE = .
RM
APP
! /home/jaume/axoloti/build/xpatch.h.gch
. /home/jaume/axoloti/objects/midiPlay/tml_impl.h
.. /home/jaume/axoloti/objects/midiPlay/tml.h
. /opt/Axoloti/app/firmware/../chibios/ext/fatfs/src/ff.h
Multiple include guards may be useful for:
/home/jaume/axoloti/objects/midiPlay/tml.h
/home/jaume/axoloti/objects/midiPlay/tml_impl.h
LINK
/home/jaume/axoloti_runtime/platform_linux/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld: /home/jaume/axoloti/build/xpatch.elf section `.rodata' will not fit in region `SRAM'
/home/jaume/axoloti_runtime/platform_linux/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld: region `SRAM' overflowed by 1096 bytes
collect2: error: ld returned 1 exit status
make: *** [Makefile.patch:62: /home/jaume/axoloti/build/xpatch.bin] Error 1
shell task failed, exit value: 2
Compiling patch failed ( /home/jaume/Dropbox/cruiser/SuperficieInestable/pd/sequential load.axp )

Both your patch that includes the custom midi player AND also the synthesizer patch work 'standalone'. But once mixed they don't.

I tried putting the synth into a patcher into your patch to no avail.

Attached is your patch with the synth in a subpatcher.

Here are some midi files:

And here is the patch
sequential load_meets_synth.axp (84.0 KB)

... which uses @SirSickSik custom midi player

Any advice on how to troubleshoot that error very much appreciated.

Thank you very much

#7

Ah! it works now

At least by removing the midi listening object.

I removed other things, but that made it.

Testing.

This is great thank you.

#8

Did a quick search on those missing files tml.h & tml_impl and landed on a conversation between you and SSS about putting them in the same folder as the midiplay object. Try to reload objects from the file menu.

Just tried your patch combined with my additions and got an sram overflow of 1520

#9

Here I got rid of a lot of the preset allocation and visual feedback (dials etc) and got it to run without an sram allocation problem......see if this works for you

VODER_CUSI_CC_CUSTOM_MIDI_PLAYER B.axp (73.1 KB)

#10

Yes thank you very much, I have accomplished something similar two posts above.

The midi to console object in particular seemed to eat quite a bit.

Seems to be working now, still testing.

Thanks

#11

Hope it works out for you, good luck this afternoon

#12

Thank you very much @reubenfinger.

Actually I think the 'load' and 'play' toggles only fire every two cycles of the second counter, instead of every cycle.

Which means that the midi files loaded are 1, 3, 5, 7... etc

I am looking into it, I suspect the change object...

Thanks again.

#13

Are you sure that the play and load objects need to to be constantly on and not just a trig, have you tested this?

#14

I am unsure.

At least the 'play' inlet, which duplicates that of the original midi player, specifies: "start on risign edge, stop on falling edge"

#15

I should add that the original jt/midi/play object uses a toggle attached to 'play'.

As far as I understand, yellow means continuous boolean-like signal, correct ?

#16

it is the logic change, not sure why, am investigating, can anyone else chime in?

#17

Thank you for your help @reubenfinger

I brought SRAM down to be able to use the 20 slots version of the patch, and I am loading 10 files by using odd slot numbers as a workaround, which is sufficient for now.

Let's see if, with more time, someone else can pinpoint what is going on, perhaps I'll start a new topic.

Thank you very much again for your help.

#18

It'll be some basic math that I have missed or misunderstood, sorry I could not get you all the way there, glad we have a workaround, hope it all goes well