Lee

Hi, Yes it makes sense to just blank out the header. It was more I was thinking of block alignment, ie RAW -> Very simple, each time around the DMA fill we simply read a 512 byte block (1 read cycle from SD card) for each voice and mix. Every DMA cycle is definitely always block aligned WAV -> 44 byte offset. First read will pull in the 44 byte header, plus remaining (512-44)= 468 bytes of audio data. Each time around the DMA fill cycle - what happens then? Does the request to read 512 bytes of audio (or whatever the WAV definition dictates) do we read 468 bytes on one read, and the remaining 44 bytes from a 2nd read? I'm not sure of the answer - I don't think the filesystem libraries cache anything (if they did, then there would be no 'performance hit' due to the block misalignment)? Anyway - if it works well in practice then it's good enough for me, this was just an area where I didn't implement WAV due to the concern over the 'double read'... Cheers Lee

Hello sample player friends! First of all, sorry for not replying to the thread for several years (I have literally been rebuilding a house, and not finished yet - so very little time for my fun projects!) I am really pleased and honoured that there's been some great contributions to the original project, well done everyone! Norbim1 - you've done a great job of adding some of the things that I would have liked to have done. I've not had time to look at the code yet, but i'm interested about the wav support as I was always concerned that with reading the RIFF header (which is far less than one 512 block) that this would then misalign the following reads of a DMA buffer length, meaning that eg for a mono sample you end up reading a block and a bit (2 reads) unless you were able to keep some of the read data in memory to make up for the read on the next block? At one stage I also had a semi-working pitch bend on the project - it worked ok for pitch bend down, but upwards didn't work! :-) I'm totally loving the mellotron project!! Nice work guys Lee

Hi, Yes it's using a microSD to full size SD adaptor as the socket (wasn't my idea, but it's a good one!). It's possible you might find a full sized SD card that's slightly faster than a microSD, but I didn't test this...

No problem... It's not so much that in order to use the LPC1769 processor you need a bootloader per se, but rather to use the Midibox (MIOS32) environment that TK and the contributors have built up does require this route. Without it, you'd have to start from scratch on all the supporting libraries and thousands of hours of development time that has been built up. Best of luck!

Thanks! :smile: It sounds like an awful amount of work to rebuild the LPC, and i'm unsure whether you could avoid building what comes prebuilt (especially as you need the JTAG USB interface initially to flash the MIOS32 bootloader onto the board). How come you can't order a board from Sweden (which is where embedded artists ship from) - that's what I did to get some boards in the UK? It's not expensive at all. As for your SVN troubles, I'll let the other guys answer here. Have you set up your SVN as per the guides, rather than just using the web interface? Cheers Lee

Having had more of a think I believe that the problem is: - Reading less than 512 bytes from the end of a sample works fine (the remaining bytes in the sector just aren't read in) - Reading from the start of a sample (or any other sector start position) is ok, as again the read just reads in a set number of bytes - Following this, all other 512 byte reads need to start part way through a sector, and then read part of the next sector. This isn't catered for at the moment (the SD card sector read routine aligns to a sector start). It is possible to sort this out (essentially will need an offset and bytes to read into a new function to do it), but it is really going to degrade the performance of the player as ALL reads following a loop will need 2 sector reads.... Hmm... I'm interesting in seeing this through to the end, but I suspect given the limits on SD card read speed we might end up with a really limited polyphony... Perhaps it is better to just allow for longer samples (ie increase the cluster position buffering) to allow people to create really long looped samples offline (and use the cheap SD storage) or take a radical fork to the project and cache really short samples in RAM... Funnily enough as we discussed months ago on the thread! Cheers Lee

Hmm, ok i've had a brief play with some test code today. I've got looping working, but for some reason it's not looping cleanly - ie there's a 'jump' in the waveform. TK! - I probably need your help again :smile: I've attached a zip file with the files for the test. There is a 1 second long triangle wave sound bank I created, which should loop perfectly (it's 200Hz, 1 second so a perfect loop). The test code is extremely limited so far in that it's hardcoded to assume a loop from the end position of a sample to the start position of a sample (should be easy to make as flexible as we need later once the basics are working). I've created a copy of the SD card sector read function to expect a specified number of bytes (rather than the standard function which is hard coded to 512 bytes). I created a copy for ease rather than potentially breaking other apps that use the function. What should happen is that the loop occurs at byte number 88200 (the full file length) after reading 172 full 512 byte sectors (so it's read up to 88064 bytes before a loop condition occurs), my code reports correctly: [7640.171] Looping sample 0, end position is 88200, start position is 0, current position is 88064 So what should happen is that it reads 88200-88064 samples (136 bytes) from the end of the sample, and then goes back to position 0 and reads 512-136 = 376 bytes from the start to complete the buffer fill of 512 bytes. What's actually happening is that it's looping (and goes on indefinitely) but there's a loud click on the loop showing that something is not happy. I'm not sure whether it's the read length not working correctly or whether there's an issue once looped of the sectors being unaligned with the number of bytes to read (as following a loop not aligned to 512 byte sectors, each read will overlap sectors)... I'm sure it's solvable but I'd be interested in some insight from TK!!! Progress, of sorts! Lee testing loop.zip

Hi, Nice to see someone else is making one! To answer the question on looping samples - as you know the code doesn't support it at the moment. It is possible to add this fairly easily, but the reason I didn't is that the player reads 512 byte sectors from the SD card, and we can usually have time to read about 8 (1 per voice) before time runs out in filling the buffer for the DAC. If a loop re-trigger happened (ie the sample being read finished and we needed to start from the beginning / loop start position again) then we'd have to read another sector containing the loop start data. This would reduce the polyphony - maybe not terribly. I suppose it depends on whether looping is more important with reduced polyphony vs maximum polyphony. My app was essentially a melodeon emulation (diatonic accordion) which tend to run out of puff on the bellows anyway! If I get time over the weekend I might have a play with looping and report back... Cheers Lee

Done! I got brain ache trying to remember all the details from a few months back... :smile: Thanks again for all your help that made it a success and fun to work on rather than a frustration!

Hi everyone, Just a quickie to mention that the player's been featured on Hackday today: here I did a write up on my site that's also got a bit of history and other info: here Hope everyone's doing good! Cheers Lee

Read the section just below half way down this page: http://www.ucapps.de/mbhp_core_lpc17.html (the schematic for the full LPC based board is around there too - the minimal bit is just the obvious parts of the USB connector, power regulator and capacitors, plus a jumper for the boot hold) And then look at the links on the top of the wiki page here for the DAC and SD card connectors: http://www.midibox.org/dokuwiki/doku.php?id=midibox_sd_card_sample_player

Hi, the player reads directly from the SDcard during playing and doesn't buffer in RAM - the processor only has 64kB! This actually works well but due to the speed of the card the polyphony is limited. When you change bank, it pre reads the positions of the sample data on the card (just the positions, not the actual data) which takes about 1 second - possibly faster depending on number of samples in the bank. Latency is fixed which at 44.1k is 5.2ms Cheers

Hi, Looks like an interesting application! It should just about be possible but you will need to get your hands dirty in the code. The project's constraints and tradeoffs are as follows: - polyphony. This depends upon CPU speed (usually fixed at 120MHz if it's the LPC board) but also the speed of your SDcard, the length of the samples and your sampling rate (the code is set for 44.1 but other guys here use lower). By default you can get 8 notes polyphony on long samples but with shorter you could get 10,12 or more - number of samples. By default this is 64 per sample bank (ie the number you want to play right now) so it could be possible to increase it - it depends how much memory is used on the processor. The memory is used to cache the cluster positions on the SDcard, and the longer the samples the more clusters - so trading off sample length (or lower bit rate) and you could increase the number of samples. I think you could easily go to 84 samples with no changes except the define at the top of the code which is set to 64 - velocity split. Currently the code only does amplitude modulation of the samples depending on velocity input. It should not be too hard to modify the midi receive routines to map to 4 sample sets depending on velocity, but you will have to add this code. I would recommend you build a 21 sample bank at your first velocity then add an offset for each velocity layer. The rest of the voice assignment code and sound output should work ok. You will have to make sure that if a note off is received then all the velocities are turned off. One thing you could add is to modify the bank file parsing to read in a start and end velocity for each sample (velocity layer) which would make it easier to create sound sets. Finally, the project only currently supports mono samples. This is purely because SD cards are slow and the polyphony discussed about would be halved if using stereo sounds (though with short samples you may stretch to 5 or 6 notes polyphony with a fast SD card). You could though perhaps do something novel like only reading mono samples but mixing seperate left and right outputs and output lower note ranges on the left and upper on the right if that's useful ? On the point about changing sound banks - yes it already responds to midi program change and i also have a rotary switch on the J10 port which directly allows selecting up to 9 sound banks at the turn of a switch. Note that if you want to ditch the laptop, then you'll need megadrum to output real 5 pin DIN midi rather than a USB interface (as the LPC code here doesn't run the USB port in host mode). This should be trivial for you. Good luck!

Sounds good, I'd be interested in the results of that, especially battery life and any noise from the conversion. As my board is only single sided, and with the DAC having a common power rail and ground (no digital and analogue) there is some digital noise, but it's not bad at all to be honest (I've heard worse on commercial devices!) :rolleyes: Oh and in the pics before anyone mentions - there's no decoupling capacitors as they haven't arrived yet!! lol

Hi all, I thought I'd share with you some pics of my pocket (well, large pocket) sample player build. It's got the regulator, midi interface and DAC under the LPC board to save space, and a headphone amp built in. The microSD is removable from outside, and you can see my 'quick and dirty' bank switch (on J10) as well as volume etc. It runs from 4xAA batteries, with the headphone amp and DAC running from 6V (or whatever it can get, obviously fine on 5V from the USB if you power it from that) and the SD card, midi interface and LPC board from 3.3V. I haven't tested the battery life, but I'm expecting 8-10 hours. It was hard to find a case of the approx right size, so the layout isn't really ideal and it's not very pretty, but it works, sounds ok and is ultimately very portable! Cheers Lee