Soundfont playing

#1

Hey guys, fairly new to the axoloti and have done some stuff with script objects for a previous project (hammond organ emulator using uart and midi for control interfaces) and want to try making an object to load and play sf2 files using the tinysoundfont library (short term goal is to implement tsf and load slender salamander grand piano). I can probably figure out the patch I/O part of the object definition, and the tsf implementation, but would tsf be technically feasible to implement and if so, how do I go about including tsf.h?

edit for clarity: tsf appears to require the inclusion of tsf.h, as well as another file like tsfi.h that implements tsf.h. I can probably figure out what to put in tsfi.h, but need to know where to put the 2 files, how to get the object to look for them, and how to get the object to look for an sf2 file in the current directory (though I can probably steal the last bit from the wav sample loading code).

#2

Take a look at tb/midi/ctrl/push.axo in the community library. That object includes .h and .c files from a directory at the same level of the object.

You can probably load the sf2 file from that same directory. It might be easier to reference it from a filename field, so it gets uploaded to the SD card automatically when you press the live button. See the file chooser XML from table/alloc 16b sdram load for instance.

#3

awesome, this is exactly what I needed. I'll take a stab at it later tonight, I suspect the biggest concern is whether tsf.h provides efficient handling of loading/unloading samples, which I assume it does in some way (havent looked too much into this yet). If not, I may try to tackle a simpler and less fully featured soundfont implementation from the sf2 spec.

On a broader note, has a soundfont implementation on axo been attempted in the past? it seems like a pretty useful object so if its been considered but not done for technical reasons itd be interesting to know why. I'm not too well versed in low level coding (correction, C is apparently high level, but about as low as high level can get), but have a decent background in discrete math which I'm hoping is enough to tackle it.

#4

I'm not a coder, but I am glad you decided to tackle the subject! I'm very keen for such an object!

#5

C is quite low-level, but fortunately, it doesn't seem to be necessary to deal with manual memory-management on the Axoloti. That's the stuff in C that always scared me.

a|x

#6

@toneburst I'm still working through the kinks of object coding (I'm fine on the script part but still a little unfamiliar with most of the object definition stuff), but the main memory issue I can foresee is too many samples being loaded. I think the best workaround is to find some way to determine which samples are more important to load, and limit the amount of samples loaded per sf2 instrument, though I havent looked enough into tsf to know if thats easy or not. I think in most cases its fair to assume memory is a far more relevant limit than dsp power for soundfonts. While there's probably not a lot of direct memory management necessary, there will at least need to be some reduction of sample loading.

The big question, which I'll be able to answer more after some testing, is whether the average soundfont still produces usable results when enough of the font is ignored to run reasonably on the axo. The main trick I plan on using is prioritizing limitation on instrument zones before limiting samples within zones if possible, since one or 2 octaves of good sound is probably more useful than a full 88 of obviously stretched and squished samples. My understanding so far is that itd probably be pretty easy to map stuff like that to attributes for testing purposes

#7

Might be easier to create on offline script in your high-level language of choice to parse a soundfont, and create an Axoloti patch from it using factory objects and binary table files for the samples.

a|x

#8

There’s an open-source project that does something similar with patches for the Nord Modular G2, parsing them and converting them into CSound scripts.

a|x

#9

Come to thank of it, if someone created a set of objects to emulate the G1/G2 modules, you could write a script to do the same, but to Axoloti patches (assuming the Nord patch file format is documented).

a|x

#10

I'd prefer to work strictly in a .axo since I'd like to make this as easy for others to implement as possible as well as teach myself more about .axo's since I have a couple broader projects in mind that would need that. As far as the nord modular thing goes, couldnt you just include the csound.h header and directly implement the modular to csound code?

#11

CSound isn’t designed for embedded systems. I very much doubt any of it would work on Axoloti.

There’s a massive difference between the processing power, RAM etc. available to a desktop application and even a relatively powerful MCU-based system like the Axoloti.

It’s a long way even from something like a Raspberry Pi, in terms of capability.

Not to say there’s not a lot of cool stuff that can be done with it, of course.

a|x

#12

The problem with making a Soundfont object is that to get it to work as a stand-alone thing, you’d inevitably end up rolling the functionality of a whole raft of existing factory objects into a monolithic single object which is essentially a black box.

This kind of goes against the modular philosophy of the patcher environment.

a|x