Lee
-
Posts
86 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Posts posted by 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...
That makes things clear! It was long time ago that I was on the midibox community. In those days it only had to do with using the SID seperatly I think? But things have changed. Your design took my attention again. ;-)
Another question. Is it right that you use a microcard adapter as connector and thus using a micro sd card? Which is a clever solution! Or did I understand/see that false? I was wandering if you also tried a full sd card in that case. My experience is that certain mini/micro cards get very slow under certain circumstances. Even very expensive ones! A full size card has totally other behaviour in the same situation. Till now I didn't discover why. But maybe it can solve the problem of cheap cards? (just using a full size cheap card) And full size sd-card connectors are not that expensive.
Last post till I really start the project and if building problems are discovered ;-)
-
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 Lee for the quick respons. I'll consider it all.
A rebuild is certainly a lot of work and as I only need one or two to get the sounds I need for
my project. The fastest way (and cheapest also at the end I think) will be using the board. Although
it's sounds strange to me (not because of your remark but in general)that these controllers only can be
programmed by bootloading the .hex But as already said I'm new to this ucontrollers! Pic and AVR are
more common to me.
I'll first try to get one in my hands of those boards :-) BTW downloading was attempted by me trough
the web interface.
-
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
First of all a big compliment to the designer of this sample player. You did a great job!
I was searching for a simple way to trigger samples with a external midi signaal. This looks perfect for it.
But I soon discovered that the used ucontroller-board is not available in Holland. Ordering in a foreign
country isn't a that big problem but they seem not to be in stock at many places. I certainly succeed in the
near future to get one in my hands :-) But looking at the scheme did me wondering the following. Is the all board
absolutely needed. Thus does the design use features of the used expresso-board or only of the used controller. So in short is it possible that a redesign of it would only use the programmed controller and not the whole board? I did already make boards with this small smd footprint. Not easy but possible with diy tools. I certainly would put a dc-dc converter on it too. So that all of it would be powered from 2 times AA or AAA. In order to get the size of the
housing down.
I think it's a challenge to give this a try if possible! But I'm new to this concerning the used controller and board. So I need opinion on this. :-)
Second question is: I can't download the full dir. at the given link? Only file after file download succeeds? Is this normal or is something overseen by me?
Keep this great project going. Thanks for sharing it. And for all the answers that maybe are given.
-
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
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
-
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
Hi Peter,
yes, I guess you're absolutely right, since I just started programming, and this would be more than copy/paste a few lines...
To get the project started I just bought a TDA1543 on ebay yesterday, but it will arrive at my place in "20-30 business days" .. dooh.
BTW, a killer feature would be a loop mode for longer samples (to play sustained notes, chords, pads, organs...). right now it's more like a Mellotron ("samples" stop after a few seconds), but this could also be nice. Maybe I make a MIni-Mellotron .. ;)
-
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!
Congratulations! :)
Your report is also nice to read!
Could you please add a link to your project page: http://www.midibox.org/dokuwiki/doku.php?id=midibox_sd_card_sample_player
Best Regards, Thorsten.
-
-
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
Awesome!
Lee, you mentioned you are using a minimal setup for the processor. Do you have a link to the minimal setup? This will live in the instrument, so the less I need, the better. I have 5V coming off of the megadrum (schematic), and I can tie in to the MIDI coming directly out of the atmega and 6N138N.
-
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
Great. Thanks for the thorough reply! I haven't yet done enough research on the components-to be sure I understand-so the currently loaded samples in the bank get loaded into memory on the processor? Are you having to read from the SD card during performance other than when changing banks? Does that only take a few secons or a few minutes? Just making sure this will work for us on stage...Have you measured latency? Regarding stereo, maybe I can modify the code to have half the polyphony and send two samples for every hit...
-
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!
Hi guys,
I was sent to this thread, as I think I'm looking for something like this. Please pardon my newbie ignorance-I have experience building audio gear - preamps, compressors, tube amps, etc, but I'm still pretty new with this type of stuff.
I built a Megadrum, and I use it to convert audio signals to Midifrom marimbas where I put piezos in the keys. Right now, the megadrum is feeding my computer via USB and I am using Reason synth sounds.
I'd like to build an onboard hardware sample solution on each marimba and ditch the computer. I was sent here, but I'm confused if the specs I need would work if I build this.
My soprano marimba has 21 keys. I want to sample each key with at least 4 layers of velocity:
21 x 4 = 84 samples
I then would like to be able to store at least four patches of sounds. So will this sampler let me store 336 stereo (stereo isn't essential, but would be nice) samples at 44.1/16 bit if each sample were an average of one second (some would be longer, but most would be shorter.
I only need I think 6 notes of polyphony at the most (we only use two mallets at a time).
Can I switch between the four banks of sound with the push of a button?
Sorry again about coming in with so many questions. I've read over the thread, and I'm afraid I just don't know enough yet to answer these questions...
PS: if you're interested in seeing what I'm talking about in action, here's a live video from a show we were recently playing (using Reason as the sound module).
-
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
That is some very nice DIY!
I doubt, that you can take it in the handluggage of an aeroplane, though :)
Am waiting for a step-up converter to power the LPC with only 2 rechargable AA batteries, but yours will have a longer battery life-time!
Greets,
Peter
-
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
-
Magneticstripper: Do you know, i've only just noticed that the performance on your video ends when you rip the SD card out of the slot, lol - that is so funny!!!
-
Whoops! I'd forgotten about that! I've rebuilt the STM version with the right environment settings and uploaded. Also taken the opportunity to clarify the project files and moved the examples for the SD card into their own folder!
-
Done!
Buhler - please give the hex file a go in the release directory for STM32 and let us know how you get on. A tip (from help earlier today) - make sure that the config and bank files have Unix style new lines, this has caught a few people out. (TK - ideally we need to fix the FILE_ReadLine to work with DOS type files, but as it just inspects a character at a time it hits the carriage return, and the new line (\n) that follows gets processed as another line - couldn't think of a 30 second fix for now!).
Thanks everyone, Lee
-
Awesome, thanks TK! It needed some previous experience of SD card fun on STM32! :smile:
Is it ok if I re-upload a new hex file? Some of the guys like magneticstripper have had success with just the hex and a bank/config file, rather than needing a compile toolchain setting up?
Thanks again, you're a legend!
It took some minutes to debug this, but with some changes it's working now on the good old MBHP_CORE_STM32 module! :)
In mios32_config.h the SRIO port was re-assigned to J16 (for STM32 only), because J8/9 is used for I2S output.
Since J16 is allocated for SD Card, and since there is no other alternative available, SRIO is now disabled for STM32.
If you will ever create a control surface for this nice little synth, it would not work for STM32. But I think that this is acceptable...
Another issue was located in APP_Init(): The "SDCARD_PowerOn" sequence was only executed once, but the STM32 core needs some retries.
I don't want to spend too much effort into this (could be related to initial pin values after power-on), but it works after I added a "MIOS32_SDCARD_CheckAvailable()" loop, which internally calls SDCARD_PowerOn as well...
This is the intended power-up sequence anyhow (polling for SD Card), therefore we should let it like it is.
The changes are in the repository now.
I deleted the precompiled project.hex from the server, because the danger is too high that we are playing ping-pong with different binaries...
Btw.: max. polyphony on STM32 is 4 instead of 8 samples (sometimes 5 can be played in parallel...)
Best Regards, Thorsten.
-
Sorry that we're no further forward on this, I have posted for debug help in the programmer's forum for someone with an STM32, but no takers so far...
-
Hi, thanks for trying! It's a difficult one for me to comment on, as I don't have an STM core... There is one thing I'm wondering about, and that is how fast the SD card is being clocked. In order to maximise the transfer speed, I set the following in mios32_config.h:
#define MIOS32_SDCARD_SPI_PRESCALER MIOS32_SPI_PRESCALER_4
This makes it 30MHz for the LPC17 core (from the default clock divider of /8 which is 15MHz). However having checked the default speed for STM32 in the SD card modules, is is already at the divide by 4 speed - so I don't believe it can be the cause of the problem.
It could be another reason why the initialisation of the SD card is failing - anyone else out there able to help?
If you have your toolchain up, perhaps try recompiling the app with this after the current initialisation:
After this:
DEBUG_MSG("Initialising SD card..");
MIOS32_SDCARD_PowerOn();
Add:
MIOS32_SDCARD_Init(0);
This is how the card is initialised in the SD card troubleshooting example, so might help potentially. Like I say though, I don't have the STM32 to test it.
On another note, as the STM32 is slower you may get quite a bit less polyphony, so as the LPCs are cheap I'd recommend moving to this platform anyway if possible.
Cheers
Hey Lee,
I finally had the chance to give this a go. Thanks for all the work you've done! I haven't even come close to getting this far with my project! I'm using an STM32 core instead of the LPC core seeing as all I have is the STM. I seem to have run into some issues. I posted the debug message I got at startup after I uploaded the project.hex. Here it is:
[126248.098] Initialising SD card.. [126248.100] Opening config file player.cfg [126248.100] [disk_initialize] error while checking for SD Card (status 0) [126248.102] [disk_read] error while reading sector 0 [126248.104] [FILE] Failed to open root directory - error status: 1 [126248.104] Failed to open config file. [126248.106] Opening bank file bank.1 [126248.106] [disk_initialize] error while checking for SD Card (status 0) [126248.108] [disk_read] error while reading sector 0 [126248.108] [disk_initialize] error while checking for SD Card (status 0) [126248.110] [disk_read] error while reading sector 0 [126248.110] [FILE] Failed to open root directory - error status: 1 [126248.112] Failed to open bank file. [126248.114] Initialising synth... [126248.114] Synth init done.
The SD card is formatted as FAT. I'm using a 1GB sd card, not sdhc or anything... I'm not sure if the issue is the fact that I'm using the STM32 or what is exactly going on... I know for a fact that the SD card reader and the core are talking as I've tested it all with the 'usb_mass_storage_device' app. Maybe the STM32 accesses the SD card in a different way? Any help is much appreciated!
-
That's totally bloody awesome! Thanks for posting the video. Your build looks great, and I'd very much like to get lost in your room, lol!! :drool:
-
Hi Jim,
I've just committed a new version which supports reading a config file in from the SD card. You can set the midi channel to anything you like now (if the config file doesn't exist etc it defaults to 1). Merry Christmas! :santa:
Hello igi - thanks for the comments. Could you explain a little further how you would want the gate and trigger to work with the sample playback?
Thanks
Lee
-
I've just added another minor but useful feature to the version in the SVN (hex and source) - it will now load bank files depending on MIDI program change. If you send a change to patch 1, it will load the bank file bank.1, patch 2 - bank.2 etc... If the patch number doesn't exist it will output nothing (no samples loaded) but upon sending a patch/bank that does exist it will then correctly load the bank and make noise again. :smile:
Hopefully this will make it easy to have multiple banks on the SD card and switch on the fly (loading a bank typically takes about a second for 64 samples, correspondingly less if your bank has less samples) - the LED on the board will be on during loading of the bank.
If anyone else wants any simple features let me know. I'm stuck for time a bit at the moment, but you never know if it's something simple!
Cheers!
Lee
-
Thanks! Out of interest, what do you use the player for?
Cheers
Lee
SD card polyphonic sample player
in MIDIbox User Projects
Posted
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