Support
Looper's Delight
|
Support |
|
|
Floyd said: >I tried dumping a loop into my sequencer. It was a long loop, >about 50 seconds. So I was prepared to be patient, but after 20 >minutes it was still sending data. The numbers in the "multiple" >window (that's supposed to be percent complete, no?) kept counting >and overflowing and counting some more with the 10's digit incrementing >about once per second or so. Midi Sample Dump is painfully slow. I just dumped a 1 second loop and timed it. It took 86 seconds to finish. So your 50 second loop would take about 72 minutes. If your sequencer supports handshaking, the process should speed up quite a bit. Without it, the echoplex adds delays in the data transmission to limit the danger of over running data buffers on the receiving device. With handshaking, the receiver can acknowledge each chunk of data so that the echoplex knows when it is ok to send the next chunk and doesn't wait. The slowness isn't the echoplex's fault. The problem is that midi is a slow, inefficient, piece of garbage. It clocks data at 31.25khz, meaning the best case is 31,250 bits per second. For each 8 bit data byte that midi transmits, it requires one "start bit" and one "stop bit." That's 1/5 of the bandwidth right there. So we are down to 25,000 bits per second. Sample Dump transmits chunks of data, or "packets," at a time, each containing 127 bytes. 7 of those bytes are protocol overhead. So we throw out another 7/127 of data bandwidth and are down to 23,622 bits of data per second. Midi doesn't stop the abuse there, because each 8 bit byte can only have 7 bits of data, with the most significant bit being 0. There goes another 1/8 of bandwidth, and we are down to 20,669 data bits per second. The sample dump standard further insists that each audio sample be justified within the 7-bit bytes, meaning we need 3 of them (21 bits) to contain a typical 16 bit audio sample. Unused bits are filled with zeros, and we are throwing away 5 bits for each sample. So we lose another 5/21 of our data bandwidth, and we finally arrive at 15,748 bits per second of actual data. Each sample is 16 bits, so we are sending 984 samples per second. The Echoplex's sample rate is 41.5khz, meaning 41,500 samples in one second of audio. 41500/984 = 42.2 seconds, just to transfer 1 second of audio in the ideal case. Adding delays to prevent buffer overflows apparently doubles this, so it ends up taking 86 seconds for 1 second of audio. The handshaking will presumably cut this by as much as 1/2, depending on how fast the receiver can deal with the data flow. Beautiful, isn't it? Just takes a LOT of patience. We added Sample Dump, actually, because everyone seemed to be complaining about the Jamman for not having such a thing. We didn't actually think anyone would find it very useful, but it was relatively easy since it didn't require any extra hardware than we already had. Be careful what you wish for..... Oh, and ignore the counter. The "percent done" part never got implemented, since we ran into so many problems trying to work around everyone else's strange sample dump implementations. > >Any advice or similar experiences out there? > My advice: start the dump and go to lunch. And if you are sending 50 second loops, make sure your sequencer can hold about 4.2 megabytes. kim ______________________________________________________________________ Kim Flint | Looper's Delight kflint@annihilist.com | http://www.annihilist.com/loop/loop.html http://www.annihilist.com/ | Loopers-Delight-request@annihilist.com