Audio file player

Thanks for the nice explanation

thanks for the correction. I was indeed thinking of the samples required to calculate a single sample, not a buffer of M samples. And thats for convolution in the time domain. But if its a finite number of samples in time domain, it will be finite in the frequency domain too.

Thatā€™s a nice illustration! :slight_smile:

very good information!

to be back on topic thoughā€¦ I did the required changes in my carla host in order to expose its internal audio and midi file players as lv2 plugins: https://github.com/falkTX/Carla/commit/9bee2ff784728453511d6d749ae8410b992059b8
tested to work in jalv. if we use presets, it should work on a mod right now as well.
I will do some tests on a duo/duox unit at a later point, but I do not see any reason why this would not work.

We need to get the file management and atom message passing working first though.
The Duo X being able to run almost mainline kernel means we can make use of the ā€œcompositeā€ devices. Initial tests are very promising (usual ethernet plus audio, midi and mass storage via usb :wink: :wink:) but any implementation has to wait for initial Duo X launch.
Great things are coming, at some point soon we shall get an audio and a midi file player :sunglasses:

4 Likes

Indeed. You could do that already with the GxLiveLooper on the MOD.
Record and save (*.wav) on the MOD, store and reload as preset.
What is missing, is a upload form, so that you could load files from your PC into the MOD.

2 Likes

This might be handled differently, with mass storage over USB.
That way we do not reinvent anything, users can just use their file explorer/manager as usual.
But this still needs a way for the GUI to list available files. We can put it inside the plugins ā€œsettingsā€ screen I guess, appearing like an enumerator parameter

Something like this open a file select dialog on a MOD UI:

  •    <button onclick="document.getElementById('file-input').click();">Open</button>
    
  •     <input id="file-input" type="file" name="name" style="display: none;" /> 
    

file handling needs to be done in javascript on the plugin side then.

I do not like this idea muchā€¦
It means either loading the file in JS or sending the entire blob over the usb network (can also be bluetooth at times), and then from the mod-ui process to mod-host. For the last part creating a file in memory and provide the path to it could work. Any file that becomes a few Mb will start to have issuesā€¦

Once we have full atom message support, these sort of things will be supported anyway.
I just fear that file management will become very messy if not thought out properly in advance.

2 Likes

The question is, at least, if you would allow/support upload and save (IR) files directly on the MOD, or if you ā€œonlyā€ would support file handling from a additional USB mass storage.
But anyway, you are right, you need atom message support to handle it right.

True, a other way would be to use a fixed path for upload a file.
So you could select a file from your PC, upload it via javascript and inform the dsp side that a new file is there. The plugin could load it then from fixed path. When save a plugin preset you could give the file the preset name to save it.
This could be done without atom support.

whatever ends up happening will be a question of what is the best user experience.
technically it is all possible.

the atom support is a given, it needs to be there to handle pretty much anything that is not parameter based.
then we need to build something on top.
once atom is there, developers can do anything actually, nothing stops someone from doing a file-open dialog in the browser, encode the contents in JS and send it to the plugin DSP.
the official supported way will be something still to be discussed and decided internally.

True, but going forward I would really like to stop doing these sort of hacks to get things going.
They work for a particular case, but then are very limited for anything other than that.
Atom messages will pretty much allow anything since they are generic by design. This on top it, full state save/restore will make it possible to do any kind of fancy GUI and interaction that one might think of :slight_smile:
hopefully the rest of the team here agrees :sweat_smile:

2 Likes

I wouldnā€™t call it a hack, itā€™s a working, simple solution. Special, when you donā€™t need those fancy GUI interaction ( consider a simple load and play button, maybe a loop button to). But true, this is only for a special plugin, not a generic solution, were you, as MOD developer might be interested in. But, from the stance of a plugin developer, itā€™s as I said, simple, powerful and, just works out of the box. :sunglasses:

2 Likes

exactly ! simple is what we need
ā€œplug in usb stick with mp3/wav fileā€ - ā€œload pedal board that has audio player pedalā€ - ā€œscroll trough the audio files found on the stickā€ - ā€œhit playā€
(oh, and a stop button would be nice)

1 Like

Can you please support MIDI start and stop with this audio file player? I would like to remotely start/stop the player via MIDI. Thank You very much for all your efforts with the MOD products! Keep up the great work!

1 Like

the player syncs to host transport, so if the transport mode is MIDI you can do that.

4 Likes

To share some progress on the audio file plugin so far, cause why not, everyone likes updates.

  • initial working modgui to test the needed concepts, works well but needs adjustment
  • can load any file that libsndfile supports (the basic open/permissive ones like wav, ogg, flac) plus mp3. I will try to add even more file support at a later point (through ffmpeg library)
  • supports looping
  • syncs to host transport
  • disk-streaming if file >30s, otherwise loads it entirely on RAM
  • always runs in stereo mode
  • tested to on work on all units

some notes:

  • duo doesnā€™t particularly like big encoded files on non-48kHz sample rate, loads them but takes a few seconds
  • there is a big difference between loading a 48kHz wav file, or something with 44.1kHz (resample needed) or even flac/mp3/ogg encoded stuff. best results are obviously 48kHz wav since there is no decoding or resampling process needed
  • looping does not time-stretch/pitch-shift or anything like that to fit into the global BPM. this is not a looper, just a player
  • currently in the beta store for those with a MOD Dwarf. if you try it, let me know how it works for you.
    (for everyone else, please be patient as we are fixing the last 3 known bugs on v1.10 Duo/X platform)

things yet to come:

  • make it run independent of host transport
  • improve the waveform preview and playhandle
  • apply all of this to midi file plugin once the audio file plugin is done

oh and a picture yes!

21 Likes

This is fantastic, and Iā€™m already thinking about some cool things to do with this.

I am still waiting for my Mod X (patiently of course) but I will be grabbing this once Iā€™m able to.

The timestretch thingā€¦ Is that something that will never be implemented, or is it something that could be implemented at another point?

Thanks!!

1 Like

Hi falkTX. Iā€™ve installed the plug-in on my dwarf but I donā€™t have a clou how to open any files. So Iā€™ve put them on the root directory of an usb-stick. Is this the right way or do I have to make it another way?

This is better done in a different plugin, something dedicated for loops.
In some months if there is nothing else like this yet, I will make one myself.

2 Likes

You need to use the file manager tab to upload your files.
It is a new separator on the bottom left.