------------------------------ Content-Type: text/plain Loopers-Delight-d Digest Volume 97 : Issue 30 Today's Topics: Re: Multitrack looper (was: Loop fea [ matthias@bahianet.com.br (Matthias ] Re: Another new member [ matthias@bahianet.com.br (Matthias ] Re: Some ideas... [ Dpcoffin@aol.com ] Re: Midi Sample Dump [ The Man Himself ] Re: Midi Sample Dump [ kflint@annihilist.com (Kim Flint) ] Re: Multitrack looper (was: Loop fea [ kflint@annihilist.com (Kim Flint) ] Re: Midi Sample Dump [ kflint@annihilist.com (Kim Flint) ] Re: Multitrack looper (was: Loop fea [ pycraft@elec.gla.ac.uk (Dr M. P. Hu ] Re: Midi Sample Dump [ Floyd Miller ] Akai S2000 [ c62op27@ibx.com (Victor Fiorillo) ] Administrivia: Looper's Delight **************** Please send posts to: Loopers-Delight@annihilist.com Don't send them to the digest! To subscribe/unsubscribe to the Loopers-Delight digest version, send email with "subscribe" (or "unsubscribe") in both the subject and the body, with no signature files, to: Loopers-Delight-d-request@annihilist.com To subscribe/unsubscribe to the real Loopers-Delight list, send email with "subscribe" (or "unsubscribe") in both the subject and the body, with no signature files, to: Loopers-Delight-request@annihilist.com Check the web page for archives and lots of other goodies! http://www.annihilist.com/loop/loop.html Your humble list maintainer, Kim Flint kflint@annihilist.com ------------------------------ Date: Sun, 9 Feb 1997 18:18:49 -0300 From: matthias@bahianet.com.br (Matthias Grob) To: Loopers-Delight@annihilist.com Subject: Re: Multitrack looper (was: Loop features, FX processor) Message-Id: Content-Type: text/plain; charset="us-ascii" Dr Pycraft said: >> >The JM is great; the only differences I'd make are >> >1. The ability to play different loops concurrently, ie like a multitrack >> > recorder where each could be muted, faded etc myself: >> This is something many dream of... >> How would you like to control those in practical terms (a key that does...)? Dr Pycraft again: >Exactly the same way the JM deals with separate loops at the moment - by >scrolling thgrough them. If I remember correctly (I'm not a user of >multiple loops) the JM shows the current active loop on the front panel, >andd operations only apply to that loop. So if you have loops 1,2 and 3 >and you want to fade 3, select it and hit "fade". The other loops continue >as before. OK you have to remember what's in what loop, but we have to do >that for multiple loops anyway. Now I am confused. I was not aware the JM was able to play its various loops simultaneously. And its your proposual for this modification that iniciates this mail... ? Or: what would be the difference between a multitrack looper and having several simultaneous loops? Hmm, you do not use multiple loops (neither do I), but would we use multiple tracks? >It's really an expansion on the UNDO key - you can start with ostinato >chords (loop 1) add a riff (2) and a melody (3), then replace the riff, or >suddenly mute the riff and melody for dramatic effect. The JM's phrased >mute would be ideal for this, as you could cue 2 loops to mute at the end >of the next bar, giving time to select and mute both. In order to keep >track of the number of concurrent loops, that number would best be kept >small and so the JM's memory wouldn't need to be overexpanded... The Plex is not able to play several loops simultaneously, so far. The idea with scrolling through loops is common to all units and ideas. But: You would not need to operate several loops as one? To "pre-operate" them with the "phrased" (JM) or "quantized" (Plex) functions might help, but in my case would not resolve, because I rarely play in respect to loop-end. I see that a extended use of multiple tracks could make UNDO and Multiply rather useless (having only 3-5 parallel loops, I would still want them!). But then, the various loops have to be of different length and synced, which corresponds somehow to the Next-Insert (TimeCopy) function of the Plex. For the operation of several loops, would it become complicated? Then, there was MiqSk8's dream: >the idea i have in my mind would involve some kind of visual feedback- click >this button, light a goes on, now you're working with loop a(b,c,d). now the >loop tools(volume, recoed, multiply, reverse, modulation((!))) are working on >that particular loop. it would require the loopy one to keep track of what's >what in a logical manner as opposed to a tactile feedback manner(hearing it). > >while i'm a complete midi novice, i'm thinking that the individual loop >information (is there one in b, what's the volume level of d) could be sent >as some midi data, which then could be sent to something with a screen (i >won't show my bias) for more of that instaneous feedback to avoid swelling in >that big loop that has nothing in it. Yes, I think display becomes very important in this context. Thats why I thought we should do it in a computer right away... Do you think a LCD would do it? Or did I get your wrong... you want to send this information by MIDI from the looper to where? Would it make sense to have a looper hardware that takes a computer to control it? >- if several loops could be concurrent the >added flexibilty of more than two outputs that would be assignable by midi >messages as well... certain extensions of the multitrack metaphor could be >applied as the idea of improvized multitrack playing is exactly what i want >to do, and if i could do it with one or two boxes instead of ten... more than >one midi in (more pedals=more control, especially for multiple concurrent >loops) and more than one out (synch, dump, once i get data in loop d start >the sequencer, i'll stop there, but even more ideas rattling me) Sounds good, all kinds of interdependent cues. For me it would be like a mixing desk with pan for each loop and at leas one Aux send, because the percussion loops I have done lately need different reverb and positioning for each instrument. But it also takes a system that my friend percussionist is able to understand... We will end up getting there! Matthias ------------------------------ Date: Sun, 9 Feb 1997 18:19:28 -0300 From: matthias@bahianet.com.br (Matthias Grob) To: Loopers-Delight@annihilist.com Subject: Re: Another new member Message-Id: Content-Type: text/plain; charset="us-ascii" Fish: ... >I originally discovered this technique while playing about with a friend's >Roland tape delay and a wah-wah pedal but it's quite easy to reproduce with >the EB16. The basic theory is to take a sound, put it through a slowly >sweeping band pass filter, delay the signal, and then feed it back to the >start where it gets filtered, delayed and fed back again. > >Now, you're probably thinking this is a bad idea and will result in the >nasty howl around feedback which we're all familiar with having plugged an >output into it's own input after one spliff too many in the studio. But >it's the sweeping band pass filter that's the key here. As the filter only >lets through a certain range of frequencies and eliminates the others, by >the time the delayed signal is fed back to the input the filter will have >shifted frequency sufficiently to prevent the signal building up into that >nasty howl. Did you try to use a compressor, maybe even in the feed back path? >Depending on the original sound and by adjusting various parameters you can >achieve a number of weird and wonderful effects. Play a big chord using >nice thick pad and pass it through the feedback loop and you get a >beautiful evolving swirl of sound as the various harmonics are picked out >and emphasized. Take a techno stab, played in time with the delay and your >riff takes on a life of it's own. Or a few Rhodes chords add a really >spacey dimension to a dub track. White noise textures also work well with >the feedback loop adding a lot of movement to the sound. And of course with >an electric guitar, which is what I first made the effect for, your average >solo will take right off into space! I would really like to hear this. I just tried to implement on the PCM80 with the M-Band algorithm, but it failed, because the filters have no Q and the feed back is limited to 100%, so its just fading filtered, which is nice, but not what you are telling us. And I am too lazy to create an analog external feedback :-) The Resonant Chord algorithm create something similar, right Greg? Matthias ------------------------------ Date: Sun, 9 Feb 1997 14:31:58 -0500 (EST) From: Dpcoffin@aol.com To: Loopers-Delight@annihilist.com Subject: Re: Some ideas... Message-ID: <970209143131_507653472@emout03.mail.aol.com> Re: SuperCollider: I got the demo on aol, and it's a gas...turn it on and let it stream cool, evolving audio at you. But it's much more than a toy (and apparently quite a handful if you're not a programmer), What follows is from the creator. the URL for the SuperCollider demo (along with a few FAQs): *** What is SuperCollider? SuperCollider is an environment for real time audio synthesis which runs on a Power Macintosh with no additional hardware. SuperCollider features: a built in programming language with real time incremental garbage collection, first class functions/closures, a small object oriented class system, a mini GUI builder for creating a patch control panel, a graphical interface for creating wave tables and breakpoint envelopes, MIDI control, a large library of signal processing and synthesis functions a few of which are found nowhere else, and a large library of functions for list processing of musical data. The user can write both the synthesis and compositional algorithms for their piece in the same high level language. This allows the creation of synthesis instruments with considerably more flexibility than allowed in lower level synthesis languages. Since it is easy to create control panels and graphic displays, SuperCollider is well suited as a tool for teaching various synthesis techniques. SuperCollider reads Sound Designer II and AIFF files and writes Sound Designer II files. It can input and output audio from either the Sound Manager or streamed from/to a file. The demo is available via anonymous ftp from : ftp://kahless.isca.uiowa.edu/pub/algo-comp/SuperColliderDemo.sea.hqx *** What does it run on? Only Power Macintoshes. It did not run on the PowerPC card upgraded Mac that I have tested because it requires the audio hardware of the Power Mac. It does not and never will run on 68K Macs. The 68K just doesn't have the horsepower for real time synthesis. *** Any particular flavor of Power Mac this works best on? The faster the better. I use it on an 8100/80. The 6100 is underpowered, especially without a cache card. I do use it on a 5300/100 Powerbook but again it is a little underpowered on that one though quite usable. *** What is the programming language like? If you would like to know more about the programming language, it is an extended version of my Pyrite MAX object. *** Is the maximum delay time limited only by available RAM? E.g. if I crank up SuperCollider's RAM allocation, can I have a 30-second delay line? Yes. All values are floats so it is 4 bytes per sample. A 30 second delay line would take up 5 Mb. *** I've never programmed and don't know how synthesizers work but I want to learn on your program. SuperCollider is probably not for beginners at programming or audio synthesis. If you've at least dabbled in both then you may find it rewarding. It is easier to use than CSound but more technical than TurboSynth. When you buy it, you get: the SuperCollider program and example patches, a 196 page manual, one year of bug fixes, updates and email support (within reason). for: $250 plus shipping ($10 US, $15 Canada, Mexico, $50 overseas). by U.S. check or international money order (Sorry, no credit cards or COD's) to: James McCartney 3403 Dalton St. Austin, TX 78745 USA ------------------------------ Date: Sun, 9 Feb 1997 13:09:02 -0800 (PST) From: The Man Himself To: Loopers-Delight@annihilist.com Subject: Re: Midi Sample Dump Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII On Sun, 9 Feb 1997, Floyd Miller wrote: > 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. > > I then tried recording a short loop, a little less than 1 second. > And the DUMP still would go on and on. > > I haven't looked at the sysex data to see if it's repeating. I don't > know if I'd be able to tell easily. The data does look like sample > dump data. I've had some similar experiences with saving Echoplex loops to computer. The manual says something to the effect of one minute for every second of loop time, but I've found it to be close to twice that amount, at least. I stored a six-second loop to computer, but it took around 10 minutes to save. You'll know when you've saved the whole thing, because the Echoplex will eventually stop sending data. When it stops crunching numbers, then it's done -- keep an eye on the front console. Saving a 50-second loop, though, could literally take hours. Make sure you've got time, and that your SysEx repository has a fairly large buffer -- I ran into much trouble trying to save to Master Trax Pro until I realized that Trax closed up after about 512 messages -- far from enough for even a short loop. --Andre ------------------------------ Date: Sun, 9 Feb 1997 14:40:43 -0800 From: kflint@annihilist.com (Kim Flint) To: Loopers-Delight@annihilist.com Subject: Re: Midi Sample Dump Message-Id: Content-Type: text/plain; charset="us-ascii" 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 ------------------------------ Date: Sun, 9 Feb 1997 19:07:24 -0800 (PST) From: cmeyer@cybmotion.com (Chris Meyer) To: Loopers-Delight@annihilist.com Subject: Re: Midi Sample Dump Message-Id: Content-Type: text/plain; charset="us-ascii" At 2:40 PM 2/9/97, Kim Flint wrote: >Midi Sample Dump is painfully slow. <...> >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.... Exactly right (from the, ahem, author of the SDS, with Dave Rossum). No handshake - or "open loop" as it is known - is extremely slow compared to the normal "closed loop" dump, which is merely painfully slow . It is worth considering a copy of Passport Alchemy or BIAS Peak (1.5 or later) to do sample dumps in a more efficient way, if for no other reason. Favorite quote: "Time is money...and the exchange rate is lousy." - CM P.S. Wouldn't it be nice if one of the so-callled data file floppy drives out there could recognize a sample dump and handshake accordingly? Were any that smart? If any one has a chance, it might be the Alesis; Marcus is no dummy... \ Chris & Trish Meyer/CyberMotion: Motion Graphics Design & Effects \ cmeyer@cybmotion.com & cybertrish@aol.com fax: (818) 598 3957 \__________________________________________________________________ ------------------------------ Date: Mon, 10 Feb 1997 00:12:50 -0500 From: Floyd Miller To: Loopers-Delight@annihilist.com Subject: Re: Midi Sample Dump Message-Id: <3.0.32.19970210000938.0068fcbc@omni2.voicenet.com> Content-Type: text/plain; charset="us-ascii" At 02:40 PM 2/9/97 -0800, you wrote: >Floyd said: >>I tried dumping a loop into my sequencer. Thanks Kim and Chris for your repsonses. I guess I was not being patient enough. I tried a gain with a short loop and it works, albeit slower than I imagined. I'll try dumping to my K2000 at some point to see if it's any faster. But I guess unless the loop is really killer and irreplaceable, it may not be worth trying to save a 50 second loop via sample dump.. A digital audio recording might be good enough. Still I am glad to have the capability. **************** ********** Floyd Miller ****** floyd@voicenet.com ** http://www.voicenet.com/~floyd ------------------------------ Date: Sun, 9 Feb 1997 21:51:21 -0800 From: kflint@annihilist.com (Kim Flint) To: Loopers-Delight@annihilist.com Subject: Re: Midi Sample Dump Message-Id: Content-Type: text/plain; charset="us-ascii" At 7:07 PM 2/9/97, Chris Meyer wrote: >Exactly right (from the, ahem, author of the SDS, with Dave Rossum). No ah...one of the responsible parties finally turns up....Welcome Chris! :-) >It is worth considering a copy of Passport Alchemy or BIAS Peak (1.5 or >later) to do sample dumps in a more efficient way, if for no other reason. Yes, and as I recall, Sound Designer worked pretty well too. If Eric is paying attention to this thread he might have some good choices too. >P.S. Wouldn't it be nice if one of the so-callled data file floppy drives >out there could recognize a sample dump and handshake accordingly? Were any >that smart? If any one has a chance, it might be the Alesis; Marcus is no >dummy... Won't it be nice when everything has firewire or fast ethernet, embedded tcp/ip and micro web-servers.....oh, what a dream....... 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 ------------------------------ Date: Sun, 9 Feb 1997 23:11:14 -0800 From: kflint@annihilist.com (Kim Flint) To: Loopers-Delight@annihilist.com Subject: Re: Multitrack looper (was: Loop features, FX processor) Message-Id: Content-Type: text/plain; charset="us-ascii" At 6:18 PM 2/9/97, Matthias Grob wrote: >Dr Pycraft said: >>> >The JM is great; the only differences I'd make are >>> >1. The ability to play different loops concurrently, ie like a multitrack >>> > recorder where each could be muted, faded etc > >myself: >>> This is something many dream of... >>> How would you like to control those in practical terms (a key that does...)? > >Dr Pycraft again: >>Exactly the same way the JM deals with separate loops at the moment - by >>scrolling thgrough them. If I remember correctly (I'm not a user of >>multiple loops) the JM shows the current active loop on the front panel, >>andd operations only apply to that loop. So if you have loops 1,2 and 3 >>and you want to fade 3, select it and hit "fade". The other loops continue >>as before. OK you have to remember what's in what loop, but we have to do >>that for multiple loops anyway. > >Now I am confused. I was not aware the JM was able to play its various Before we get too far with this, lets try to define some terminology. We had to do this when we started thinking about these ideas at g-wiz long ago: Loop - a potentially complex set of media data, repeating in some fashion in time. A "Loop" can contain one or more "tracks." The tracks repeat in some relation to the loop repetition rate, and may all be synced together in equal lengths or have complicated time relationships to each other. Any looper, no matter what it's features, would only play one loop at a time. When we talk about multiple loops, we mean things that are discreet from each other in time. So you might switch from one loop to another, but you wouldn't play two at once. If you did, you would still have one loop, but it would just have more tracks. Got that? Track - A singular set of media data, available to be repeated in some fashion within a "loop." A track can be operated on with the various loop functions we have available. So the echoplex and jamman have multiple loops, but really only use one track at a time in a loop. Some of the functions give the appearance of multitracking, like overdubbing on both of them, and multiply and undo on the plex. Then there are all sorts of things that can happen in a multitrack environment. Grouping, copying, different processing on each track, defining relationships between tracks, etc. Really a whole new set of performance functions. How you put all that in a usable interface, that makes sense for real-time, live usage, is the tricky part! 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 ------------------------------ Date: Sun, 9 Feb 1997 23:18:23 -0800 From: kflint@annihilist.com (Kim Flint) To: Loopers-Delight@annihilist.com Subject: Re: Midi Sample Dump Message-Id: Content-Type: text/plain; charset="us-ascii" >At 02:40 PM 2/9/97 -0800, you wrote: >>Floyd said: >>>I tried dumping a loop into my sequencer. > >Thanks Kim and Chris for your repsonses. >I guess I was not being patient enough. >I tried a gain with a short loop and it works, >albeit slower than I imagined. > >I'll try dumping to my K2000 at some point to see if it's >any faster. Best not to try the k2000...it won't be supported in the echoplex sample dump for a while, because it requires some special features that we have to add. If I remember right, the k2000 adds 200 to the sample #, and doesn't subtract it out again when you try to send back to the echoplex. The current echoplex soft doesn't like that much. It'll be there eventually. 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 ------------------------------ Date: Mon, 10 Feb 1997 12:26:00 GMT From: pycraft@elec.gla.ac.uk (Dr M. P. Hughes) To: Loopers-Delight@annihilist.com Subject: Re: Multitrack looper (was: Loop features, FX processor) Message-Id: <15193.199702101226@rank-serv.elec.gla.ac.uk> Content-Type: text/plain; charset="us-ascii" Michael: >The JM is great; the only differences I'd make are >1. The ability to play different loops concurrently, ie like a multitrack > recorder where each could be muted, faded etc Matthias: >Now I am confused. I was not aware the JM was able to play its various >loops simultaneously. And its your proposual for this modification that >iniciates this mail... ? No, it can't - but I'd like it to.... :) >Or: what would be the difference between a multitrack looper and having >several simultaneous loops? Matthias again: >Hmm, you do not use multiple loops (neither do I), but would we use >multiple tracks? I think so. Before I got my JM I assumed this was how multiple "loops" worked. I'd like the ability to loop a verse with chords and a bassline, then keep the bassline but drop the chords out for the chorus, then bring them back. Or fade between one theme and another without losing a fundamental pulse or riff. I think that, for example, it would help you do the kind of music on your cassette (review to follow soon, folks) without editing later, ie live. >You would not need to operate several loops as one? >To "pre-operate" them with the "phrased" (JM) or "quantized" (Plex) >functions might help, but in my case would not resolve, because I rarely >play in respect to loop-end. >I see that a extended use of multiple tracks could make UNDO and Multiply >rather useless (having only 3-5 parallel loops, I would still want them!). >But then, the various loops have to be of different length and synced, >which corresponds somehow to the Next-Insert (TimeCopy) function of the >Plex. For the operation of several loops, would it become complicated? Probably, but it would be worth it. It would give more control overt the evolving stucture of the music. To help resolve this, Kim provided: >Loop - a potentially complex set of media data, repeating in some fashion >in time. A "Loop" can contain one or more "tracks." The tracks repeat in >some relation to the loop repetition rate, and may all be synced together >in equal lengths or have complicated time relationships to each other. Any >looper, no matter what it's features, would only play one loop at a time. >When we talk about multiple loops, we mean things that are discreet from >each other in time. So you might switch from one loop to another, but you >wouldn't play two at once. If you did, you would still have one loop, but >it would just have more tracks. Got that? THAT'S IT. I don't wan't multiple loops, but multiple TRACKS with individual control over each TRACK, or at least the possibility of controlling 2-4 tracks with layered looping in each track. Matthias once more.. >Yes, I think display becomes very important in this context. Thats why I >thought we should do it in a computer right away... Michael: Naah... A MAC on top of a marshall stack does _not_ look good.... Dr Michael Pycraft Hughes Bioelectronic Research Centre, Rankine Bldg, Tel: (+44) 141 330 5979 University of Glasgow, Glasgow G12 8QQ, U.K. "Wha's like us? Damn few, and they're a' deid!" - Scottish proverb ------------------------------ Date: Mon, 10 Feb 1997 08:29:57 -0500 From: Floyd Miller To: Loopers-Delight@annihilist.com Subject: Re: Midi Sample Dump Message-Id: <3.0.32.19970210082927.00691234@popmail.voicenet.com> Content-Type: text/plain; charset="us-ascii" At 11:18 PM 2/9/97 -0800, Kim wrote: >Best not to try the k2000...it won't be supported in the echoplex sample >dump for a while, because it requires some special features that we have to >add. If I remember right, the k2000 adds 200 to the sample #, and doesn't >subtract it out again when you try to send back to the echoplex. The >current echoplex soft doesn't like that much. It'll be there eventually. > Ahhh. Yes the K2K does that. What does the Echoplex do with the sample#? Does it use it to say which loop # ? **************** ********** Floyd Miller ****** floyd@voicenet.com ** http://www.voicenet.com/~floyd ------------------------------ Date: Mon, 10 Feb 97 09:14:49 EST From: c62op27@ibx.com (Victor Fiorillo) To: Loopers-Delight@annihilist.com Subject: Akai S2000 Message-Id: <9702101414.AA03459@ibx.com> Does anyone have any experience using the Akai S2000 sampler for looping applications? Victor --------------------------------