Jump to content

SD card polyphonic sample player


Lee
 Share

Recommended Posts

Hey,

just wondering: would it be (theoretically) possible to merge this player with another application, e.g. the new MidiBox KB?

I have an old Solton Keyboard I want to "midibox", and having this player would make it a nice little sample keyboard. Would be great if this would only use one LPC17, but don't know it this would work at all... I guess polyphony could suffer.

cheers,

Lars

Link to comment
Share on other sites

Hi Lars,

It might work if you have tha coding skillz :)

but, i wouldn´t do it, a core + lpc costs much less than the time that would be necessary for it, and you can wire it up all within the keyboard, so nobody sees that there´s two cores involved :)

Bye,

Peter

Link to comment
Share on other sites

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 .. ;)

Link to comment
Share on other sites

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 .. ;)

Link to comment
Share on other sites

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

testing loop.zip

Link to comment
Share on other sites

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

Link to comment
Share on other sites

  • 2 weeks later...

Lee,

thanks for a great project, just finished mine. I am sure it will be most useful.

To anyone else considering building one, be aware that the TDA1543A is different to the TDA1543.

I used a TDA1543A, wrong!

It works great now I have a TDA1543.

Tim.

Link to comment
Share on other sites

  • 2 weeks later...

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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!

Link to comment
Share on other sites

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 ;-)

Link to comment
Share on other sites

  • 1 month later...

Anyone who can give a little help? svn downloading the files gives me trouble. Websvn doesn't work and after installing Tortoise I still get errors.

svn is clearly as it shows not my thing till now :-) What's wrong? I've created a folder and check it out in Tortoise. After that I put down the svn link given

on Lee's site. But it doesn't work!

Edited by Fret_.__B
Link to comment
Share on other sites

  • 2 weeks later...

So I tried just copy-pasting the project.hex from /trunk/apps/synthesizers/SD card sample player/release/LPC1769/ into a text file, saving it as project.hex, and uploading it to the board with MIOS studio - I don't know if it was a good idea, but at least the smoke that drives all electronics didn't come out :-) Nothing else happened either, though.

On the left hand side of MIOS studio I get:

Operating System: MIOS32

Board: MBHP_CORE_LPC17

Core Family: LPC17xx

Chip ID: 0x26113f37

Serial: #21802121DAD04535CAB169D42000005F

Flash Memory Size: 524288 bytes

RAM Size: 65536 bytes

Bootloader 1.008

© 2009 T.Klose

, so I suppose I've managed ok this far. However, browsing for the copy-pasted project.hex and trying to upload it, I get:

Reading project.hex

Trying to contact the core...

project.hex contains 53136 bytes (208 blocks).

Range 0x00000000-0x0000cfff (53248 bytes) - PIC Bootloader (ERROR!)

ERROR: Range check failed!

I don't know whether the problem is with my DIY hex file or with something else.

Link to comment
Share on other sites

As the extension .hex suggests, this is NOT a text file. Text files will not work. Hence, if you copy its content into a text file and only change its extension to .hex, it will remain a text file and continue to not work. Try the "Save link as..." option in your browser, from the page linking to the file.

Link to comment
Share on other sites

As the extension .hex suggests, this is NOT a text file. Text files will not work. Hence, if you copy its content into a text file and only change its extension to .hex, it will remain a text file and continue to not work. Try the "Save link as..." option in your browser, from the page linking to the file.

Hi,

at least hex and text almost rhyme :)

but choosing 'Save link as' on the project.hex file gives the link to be saved as "filedetails.php". I guess there is no way around using Subversion to download the hex from the location given in the project wiki page.

http://svnmios.midibox.org/listing.php?repname=svn.mios32&path=%2Ftrunk%2Fapps%2Fsynthesizers%2FSD+card+sample+player%2F

If I read it correctly, though, the hex in the release folder hasn't been changed for 270 days, so on a layman basis it would seem it's not under feverish development, and hence it *might* seem that making a plain-and-simple downloadable hex available (like there is one for MIOS32 bootloader) would be a one-off affair..? Be that as it may, naturally I'm not in a position to demand anything from anyone in this respect, so if the developers of the project have no time, then they have no time - fair enough.

Link to comment
Share on other sites

This is what a programmer friend told me to do and what I did in Ubuntu 12.04.

sudo apt-get install subversion

Then, in terminal, cd into target folder and run

svn co svn://svnmios.midibox.org/mios32/trunk/apps/synthesizers/SD\ card\ sample\ player/release/LPC1769/

Now you have LPC1769/ in your target folder.

For some reason or another I had a feeling I would need to install apache2 first, but I don't know if that was necessary because I didn't try svn on the command line before I installed it. Anyway, should that be necessary, type:

sudo apt-get install apache2

I wasn't really sure what I was doing but it worked, which is good enough for me.

Edited by jjonas
Link to comment
Share on other sites

  • 3 weeks later...

Thanks for the SVN info given by other users. It was very helpful!

Ubuntu did the job for me also after problems with several Windows applications for SVN.

I think the proper way to connect to the directory-structure could be the problem?

But after reading about the Ubuntu solution it's perfectly solved! I finally have the project file in my given dir ;-)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...