Hi there,
I'm currently working on a patch that uses 6 Play fn objects that are triggered with LFOs. Annoyingly I'm getting clicking sounds that I can't work out the cause of. Can anyone help troubleshoot?
I'm using 48khz/16-bit .raw files, none of which are longer than 4-5secs
"wave/play.." is highly dependent on sdcard performance, and the speed rating on the card is not very indicative of the actual performance.
For a limited set of short samples, I recommend loading them into sdram tables, using "table/alloc 16b sdram load" and "table/play". There is room for 83 seconds of mono 48kHz 16bit audio in sdram.
I have another question regarding how 'table/play' deals with samples; is it polyphonic in a sense that if I was to trigger a sample twice, would both play through independent of each other, or would the second instance stop the first from playing?
"table/play" will play independently in a polyphonic context. To share one table, you can allocate (table/alloc..." it in the parent patch, and reference the table in the sub-patch by using "../table1" as a reference.
By doing this, if I then allocated a button to trigger a sample, would pressing the button before a sample is finished trigger a second instance of the sample?
hmm polyphonic subpatches only handle polyphonic voice allocation for midi input. One way around is generating "internal" midi note messages with "midi/intern/note", and catching them with "midi/in/keyb" in a polyphonic subpatch.
The other way is explicit cycling between table/play objects, something like this:
Thanks Johannes, I've been trying to patch your first option, but I'm not sure I fully understand. Could you post a screengrab of an example patch please? Sorry, I'm quite new to this still!
I believe the key to removing the clipping sound on a wave/play object is to change the input position to something just above 0. I'm not sure the scaling, but setting this to 0.001 works very well for me. I've got four simultaneous samples. It doesn't respond to the fastest of finger banging, but at that point, what is the difference in cacophony?
I suspect it's going to be dependent on the length of the sample whether it clips the beginning of the sample or not, it would probably be better to add an object that allows you to type in an exact integer value and setting that value to the byte position that the data portion of the wave file starts.
Hmm. From looking at your picture you are using .wav files, which in Axoloti context produces clicks when retrriggered, even when using "wav" player.
I think a better solution would be converting the .wav files to .raw files. Then you get no clicking. This is better solution than moving the sample start point, like you do in the picture. I have build several "drum sample players" in Axoloti, using the same objects and I have no clicks when using .raw 
imho setting an offset for a wav file is the best solution because it doesn't need you to open up a wave editor and export a raw audio file for every single sample you want to put into axoloti, it would be much better to have an object that handled real wave files without user intervention.
Personally I've got far too many samples to be converting them all to raw.
That was my initial thoughts too. Way too much work. And it can be daunting in the beginning. But Also rewarding when done. I have converted thousands of files, wavetables, wavefiles, etc... And they all works flawlessly, no clicking no nothing. Making an offset is the easy way, NOT the best nor the right way.....
Anyway, it was just a suggestion. Do what you feel is best But dazzling duke were asking for a way to remove those clicks... And converting them to .raw files IS the best way. Fix it at the source is always the best, but yes, it does involve some work to be done.
I agree, whatever way you find the most comfortable is usually the right way. I wondered if there was a reason wave files weren't being handled correctly? Is there a licensing issue or just that no one has coded the solution yet?
If it's just because no one has coded a solution I might look into it and see what I can come up with 
It is because .wav files has got a fileheader that tells you that it is a wav file. And when using with Axoloti, the fileheader of .wav file(or any other format probably) WILL make a small click. That is just how it works. You can search the forum and find same description many other places in here.
But .raw files doest not have a fileheader. It is raw. Therefor it does not produce clicks. That is the explanation for it.
Right, I understood that part, so it's because the header handling code hasn't been written yet then? 
I don't know if we should expect it to be written at all. I think it has been discussed in here somewhere. But I think you will get a better answer if you make a new thread and ask the developer instead. He knows what direction Axoloti is heading in the future.
You misunderstood my questions, I don't expect anyone to write anything for me/us at all, I was just asking if there was a reason why it hadn't been done, licensing or some other reason, if it's licensing then that probably means that no one should write the code (unless they pay for licensing if it's necessary), if it hasn't been written just because no one has done it yet then that doesn't stop anyone from writing the code, someone like me for instance! 
I only said that you should search the forum for the reason Axoloti uses wav files as it does. I dont remember. And since I cant really code, besides basic editing og objects, I use it as is
But as far as I remember it has been discussed before, so you should be able to find the reason by doing a search.
No, Axoloti doesn't handle wave files, and stripping headers (or resampling etc)
there are a couple of reasons not to do it in the firmware:
- to get the correct offset you have to parse the header ... = cpu usage when you load the file.
- @johannes has mentioned something about SD card formats and the blocks sizes, meaning you'd be reading at an inefficient block start. (badly explained, but its detailed on the forum somewhere )
I think the preferred approach, would be to have the axoloti UI actually 'convert' the file, as it is uploaded to the SD Card, so the 'effort' is only once at upload time, and the board doesn't have any overhead.
(this could also later extend to other things, like resampling from 44k to 48k)
if your doing a large number of files Id recommend using ffmpeg from the command line, a quick script and you can do thousands of files in seconds
I dont really find this much of a bind frankly, as often I have to resample the wav files anyway, so this can all be done in one step.
like anything, first time, it takes a while to figure it out, but after than it becomes very quick.