Is this sort of manipulation possible or is the sampler chip more Paris Hilton than Tina Fey (that is, "dumb")? Again, I haven't finished mine yet, but I can see myself wanting to "nudge" the loop this way or that. Again, it might not be what WTPA is meant to do.
I'm sure I'll have tons more suggestions when I get my party going.
So, I'm thinking about a simple "scrub" function that scrolls through the sample as it plays. Maybe it could be a MIDI-only effect, like jitter. (Then again, the control pot could, er, control it.)
The WTPA can already reverse and rearrange samples...maybe it can do this.
Ok, I'll explain what I'm talking about a bit more in depth (and talk in quasi-pseudo-code):
For "start, end, loop point adjustment": Start - this is where the recorded sample "starts". If = 0, playback the sample normally (start at the beginning of the memory address). If > 0, start the sample at that address in memory. I'm not sure about the exact jargon, but let's say the sample in memory is 1024 bytes long; if "start" = 256, start reading (playing) the sample at that point. If the machine is in loop mode, when the entire sample has played back (that is, has reached the "end" of memory), start again at the "start" location (256, in this example). End - just like sample start, but this setting dictates where the sample in memory ends. (If in loop mode, the sample starts at the "start" location when it reaches this "end" location.) Loop Point - this parameter might be more complex than what you intended the WTPA to do, but it's where the sample starts over after it reaches the end. So, if this was implemented, this would be the playback order: start, end, loop, end, loop, end, ad infinitum (if in continuous playback mode; if not, just go to start, end, loop, then end.) The loop point value cannot be less than the start value and greater than the end value (or maybe it can...?).
"Scrubbing" the sample: This one is harder to describe, technically. Conceptually, think of what used to happen with the very first CD players when you hit fast forward or rewind: you heard tiny slices of the song until you reached your desired location in the track. This happened because the laser was reading and playing the point in the song as it was moving. This differs from start point in that the memory is read at wherever the "playback head" is located, at that moment. Example: sample is 1024 bytes long. Start = 0, End = 1024. The sample plays normally until a value is received for this new parameter (from the control pot or midi CCs), let's say 256. The playback begins immediately at 256, no matter where or what it was doing, then plays to the end of the sample. Upon the next loop, it plays normally.
So those are my brief explanations. Let me know if you'd like some use cases or further details. I understand that these suggestions may be out of the scope of what the chip or firmware can do, but they're just ideas. I'm sure I'll have a ton more.
The start and end point adjustments would be easy enough to do for normal looping functions, and would take a little more math when playing samples in a non-linear (granular) way. Also, I worry that with the current input pot scheme and MIDI parameters you might not be able to set the start and end points in a very precise way without some very creative programming. But it could be done.
This also means that "Scrub" might have to be more like a "fast forward" button. Or like the "scratch" function on one of those amusingly silly CD-DJ players.
Is this something you have found yourself wishing you could do when you're using WTPA?
The inspiration behind some of these things is the Elektron Machinedrum's RAM machines. It has start, end, and "retrigger" functions, which can be tweaked in realtime. I can't tell you how many hours of my life I've used (wasted?) on those three knobs alone. Start and end point adjustment is probably more for the MIDI crowd, but I can see benders and live-jammers finding some joy in a little more accuracy. (For example, instead of relying on good reflexes, which many nerds lack, finding the start of a kick transient within a sample would require a little nudge on the start "knob".)
Besides being a nice "utility" function, changing the start/end points in realtime (not "realtime mode") could make for a really cool effect. The old Akai samplers allowed you to edit start/loop/end points in realtime (but with only one sample), while it was playing. The effect sounded like instant Autechre. (By the way, if start point > end point, maybe the sample could reverse.)
The "scrub" idea came from something on the MIDINES, by Wayfar(.net). Basically, you could traverse the wavetable memory, as the sample (or samples) were playing. Come to think of it, this is just like the start point adjustment thing. Dang. Nevermind about this one! I wouldn't want you wasting time on such this.
As long as one could have the sample continuously play whilst adjusting start/end points, these features would bring the WTPA to a whole 'nother level.
Sorry in advance, with awkward smile: Firmware updates will be handled via good ol' In-Circuit-Serial Programming. Writing a MIDI bootloader and the associated crap for the Linux/Mac/M$ end seemed like no fun, and so far noboby's asked about it. ISP allows you to so much, so easily, when you're in nerd world.... I'm sure when the first major update happens I'll need to figure out something about getting the new firmware to the old folks, but it'll probably just involve posting the hex file and a brief how-to. Those who are _REALLY_ strapped can always buy a new MCU, but it seems a waste. And, honestly, part of the reason this is a kit and not a finished product is the idea of pedagogy -- of having people learn about electronics. So yep, while the ISP update will be annoying for a lot of people, it can't really be much more annoying than, oh, that damn SRAM chip.
WTPA's firmware is in ANSI C, compiled with GCC 4.3.x. There are a couple lines of assembly in there, and GNU Make handles the build. Pretty standard.
My favorite is the STK500, which is $79 from Digikey -- I use it all the time and have bought several. The AVRISP is $34, and I know tons of people use it. There are a million kits out there too which are a little cheaper, I think. Betcha Sparkfun has something that a lot of DIYers like. Hope this helps, TB
Well, it's sort of disheartening to know that I'll have to drop a few more bones on an AVR programmer, but I think this sort of thing will come in handy for future projects. It's just another step in nerd-evolution! I can feel a pocket-protector growing out of my chest.
So I'm not an owner of a finished WTPA, or even of the kit yet, though seriously considering it. So with that in mind, especially not having the experience and joy of playing with it yet in its current state, this thread embodies what I think is its current biggest limitation - not being able to edit in any way what you have sampled.
I think the idea of adjustable loop start and end points is an awesome one, but let me add one suggested modification: make the loop start adjustable, but then make the other variable loop *duration*, rather than loop end. Why? Because then you can do what I used to do all the time on my Ensoniq EPS - make a very short duration loop (even just a few samples), and then "move through" the sample by adjusting the sample start point. Instant granular-like effect, and very controllable for all kinds of cool sounds!
I would also love to see USB (or MIDI in a pinch) transmission of sample data back to a host computer, to be able to edit samples there. In addition, you could load pre-existing samples onto the WTPA this way.
dnigrin "make a very short duration loop (even just a few samples), and then "move through" the sample by adjusting the sample start point. Instant granular-like effect, and very controllable for all kinds of cool sounds!"
Man, that would be freakin epic if able to be done. If not on this version of the WTPA, maybe the next? Would be excellent.
I thought about this a lot when posting the initial idea and came to the conclusion that you could accomplish everything just by moving the loop points. Want a shorter loop? Just move start, end, or both loop points to the desired length. Want to go to a different part of the sample with that same loop size? Just move the start and end points in tandem.
Sure, a dedicated control for the loop (that is, the space in between start and end) would be great, but possibly superfluous. I guess my concern is that this relatively "simple" feature to add could amount to some complex code; we don't want Todd to burn out on V1!
That being said, if Todd can throw it in WTPA V1, why not? (Really though, Todd: if there's only one feature you add in V1, let it be the start and end points...pretty please!)
glitched "I thought about this a lot when posting the initial idea and came to the conclusion that you could accomplish everything just by moving the loop points. Want a shorter loop? Just move start, end, or both loop points to the desired length. Want to go to a different part of the sample with that same loop size? Just move the start and end points in tandem."
Funny, we came to different conclusions when thinking about the same thing! :-)
I think your last line is where the challenge comes in; to do that "windowing" effect, where you move through a sample with a very short loop, it's important to try and keep the loop duration pretty much fixed, so the "move start and end points in tandem" I think would be tough, especially if these were controlled by physical pots.
I came to the conclusion that with just start point adjustment and loop length adjustment, you could eliminate the need for end point adjustment; the only requirement is that you adjust your start point first.
My C skills are rusty, but I'm going to download the code now and see if I can take a peek myself... I agree though, that the main thing to consider is whether Todd can do it!
It makes more sense to do it on rev 1 hardware and then port it forward than to write it on the next rev and port it back. The code shouldn't be that bad to do, since I'm pretty sure I won't have to do any more processing in the audio interrupt -- the calculations can all get done from the main loop and it shouldn't make for any more audio latency.
However, it does seem like there are conflicting views about how exactly the processing should get done: I'm inclined to weigh in and say the sample start / sample duration method might work better simply from a control system point of view. There is currently only one parameter control knob on WTPA, which means that in caveman mode it isn't really possible to adjust two points in tandem. Naturally this is no biggie in MIDI, but not everybody in the WTPA community is up on that yet.
Another idea might be to make three controls: Move Sample Start Point, Move Sample End Point, and Shift Sample Window. The first would be identical to what glitched is talking about, and the third would simply move the sample beginning and end points forward or backward in memory by an equal amount -- which is the effect that you are talking about, Dan. Does this sound correct?
We also talked about the idea that when a sample's end point is moved before its start point it plays backwards. Does that seem right? I like it. I'm also inclined to think about the sample as a circular buffer wherein if you moved the end point past the end of the sample it just moves forward through the beginning.
Let me know what you all think, and thanks for hashing it out!
Best, TB
ps. @glitched -- I'd love to take a look at your friend's OS for the x0xb0x, 'cause I like OSes. Though I get a little queasy having to touch Ladyada's indentation style...
"Move Sample Start Point, Move Sample End Point, and Shift Sample Window. The first would be identical to what glitched is talking about, and the third would simply move the sample beginning and end points forward or backward in memory by an equal amount -- which is the effect that you are talking about, Dan. Does this sound correct?"
That's it. SCI Prophet 2002 had similar controls.
What would be nice is a "sample edit" mode where 4 buttons increment/decrement the start/stop points by one frame and the parameter knob would set the length of the sample from max to one frame..
"Another idea might be to make three controls: Move Sample Start Point, Move Sample End Point, and Shift Sample Window. The first would be identical to what glitched is talking about, and the third would simply move the sample beginning and end points forward or backward in memory by an equal amount -"
YES! I would love to have exactly this on the WTPA :)
While im here, I'd love to try that Sokkos OS for my x0xb0x. But Damn, it looks like such a pain in the ass to change firmware on a x0xb0x. Theres like, 5 different installs needed on my Mac to do it. And im still completely lost on what to do with it all :( All that python crud makes my head spin.
Back to WTPA loop shift hoopla. Todd. I'll thank you in advance for this, because it will be great :D
"Move Sample Start Point, Move Sample End Point, and Shift Sample Window. The first would be identical to what glitched is talking about, and the third would simply move the sample beginning and end points forward or backward in memory by an equal amount -- which is the effect that you are talking about, Dan. Does this sound correct?"
For me, although this is very close, it's not optimal. Here's why - I think adjusting the sample end parameter will be of most use when trying to trim off excess junk off the end of your sample, for use when looping most of the sample, or for one shot mode. So say I sampled Public Enemy's "Hear the drummer get wicked", but all I want to loop over and over, or just have for one shot, is "Hear the drummer". Fine.
But for "Shift Sample Window" mode, I think the most creative uses of that will come from using very short segments - like just the beginning of the letter H in "Hear" for example - and then moving that window through the sample. So in this case, I'd need to move the sample end parameter very close to the sample start parameter, and then use the Shift Sample Window mode to move through. OK, but then when I want to just go back to one shot mode or traditional looping, I'd have to reset the sample end to get my "Hear the drummer" again.
I think better would be:
Sample Start Sample End Loop Duration
Loop Duration adds the value of the pot to whatever the Sample Start parameter is currently set to, up to a max of Sample End, to determine how much of a window to loop. So using my example above, it would be very easy to set a very small Loop Duration, and then switch back to Sample Start mode and use the pot to "move" through the sample while looping.
I hope this makes some sense!!
At any rate, Todd, thanks in advance for giving this a go, whatever you decide to do!! I'm still going to try going through the code to see if I can take a crack at it, but I have a feeling you're gonna beat me to by a long shot...
@glitched, cool that you know the SokkOS guy, that's a nice piece of work!
Todd: you have it exactly right. Those functions are what we're talking about. I like Altitude's suggestion of an edit mode, but my idea of the control scheme differs:
In "sample edit mode": Let's say we have the three functions: start point, end point, and loop window. Assign buttons S0, S1, and S2 to those functions, respectively. Use the control encoder to modify the selected parameter.
For instance, let's say we want to move the start point. Click S01. Now we're in "start point adjustment mode" where moving the control pot changes the start value.
Maybe S3 and S4 could increment/decrement the parameter's value by one "slice" or "frame".
Anyway Todd, if you want to check out the SokkOS, go to my x0x-specific site and download the latest firmware, with source: http://x.glitched.org/
The firmware should be a great starting point because one of the hallmarks of it is the ability to change start/end/loop points, on the fly.
One thing I realized - we might want to consider a "truncate" function to free up memory after adjusting loop start/end points...
My kit arrives today - now just gotta build it so I can stop speculating about using this thing and actually do so!
Also, I took a look at the firmware code last week, and I can see pretty much all the spots that I think need modifications to make this all happen... I'm sure Todd knows this stuff in his sleep and will probably think of all kinds of things that I didn't, but to my naive eyes, it looked like mod should be quite do-able!
So I built my kit last night - loads of fun! Worked straightaway, no problems at all (and I'm a surface mount newbie, and did that successfully too). Will post pics/video and stuff when done mounting etc...
But in the meantime, I was wondering about something with respect to these feature we've been talking about. Todd, on the existing effects the way they work now, it seems like the pot is queried once at the time the effect is invoked. So for example, with the bit reduction, you set the amount you want to reduce with the pot, *then* invoke the effect.
With several of the features we're talking about here, the pot will need to be polled frequently - will that be a problem? Is there a limit to how frequently you can poll it in the software?
Also - if I begin to try and make some changes to the firmware code, would you like me to use some kind of versioning system like CVS or Subversion or something? It's doubtful that I'll get it to the state where it will be ready for prime time, but at least then you'd have something to work from, and you could see what I changed and where...
BTW, after now playing with it, I *really really really* think these changes to the firmware will make it even cooler!!! One of the things I noticed is that there are often just segments of a sample that I really love the sound of, but was forced to have to listen to/use the whole sample to hear it. Being able to edit down the sample to just that section will be awesome, as will the loop position thing...
As I said, this feature will bring the WTPA to the next level. I don't care about the truncation (because I never record long samples and am not affected by the memory limitation), but being able to mess with start/end points in realtime will be the dog's bullocks.
@dnigrin -- Don't worry about versioning. Just write something cool. I'll use diff to see your changes, like my name was Richard Stallman. The control pot is sampled checked every loop through the state machine and updated when the ADC has valid results. Look for the "potValue" variable to figure out what's going on. Polling speed will be no big deal. The rotary encoder will be even faster....
@everybody else -- OK, OK :-)
1.) The truncation is not going to happen. While you could permanently set the start and endpoints to different places with a truncate command, freeing memory is a lot more complicated because of the fragmentation it would introduce. Actually being able to use the RAM you freed would require a memory map or some sort of more complicated memory allocator. I looked into this when I decided WTPA should be multi-timbral and it was not trivial to implement in real time. Therein lies the reason WTPA only stores two samples at a time, because keeping track of the memory for two is pretty easy.
2.) The start/end features are doable and I've got to do them soon, because I really am scraping the bottom of the WTPA barrel for this revision and I promised all y'all I'd make this revision to the first firmware. Perhaps this weekend. And yeah, they do sound like they'd be cool....
Thanks again for all the tips, everybody. This is exactly why I have a forum! Best, TB
@Todd: Thanks for responding to consumer demand! Adding these things gives WTPA v1 (the "OG" version) it's own place in the Narrat1ive product line. It has tons of functionality, but you have to put it together yourself. V2 is the deluxe version with 4 sample channels, a high pass filter, sample storage, and, as a bonus, when it becomes sentient, it won't kill you!
I'll be happy to test whatever you put out because, as you know, I'll be rocking the MIDI side of things pretty heavily.
w/r/t pot polling -- I'd like this feature as well... I think it would be nice if you could hold down say an effect button and get an incremental change, for bit reduction, etc... obviously that's already being done (in everything but realtime mode) because you're updating those LED's -- but was that a design decision to only apply the value from the pot to the effect when you hit the button and not "while you hold the button"?
@smrl -- That's a good idea. It will require some fiddling with how the keys are polled but I think it won't be a big deal to implement. I'll shoehorn that feature into the next revision, like my name was, um... The Fedora Development Committee? No Richard Stallman, I know. Best, TB
@Todd: OK, will send what I've got your way via email, probably tomorrow or the day after.
OK on no truncation, not a big deal.
@Todd and smrl: Yes, smrl's gotten exactly what I was talking about on the polling stuff, both for the new start/end/loop position stuff, as well as for existing effects. So if you can do this Todd it would be really great.
*Start/loop/endpoint adjust *Subtractive summing (my idea, nobody asked, but I think it'd sound cool) and maybe absolute value conversion *Parameter adjustment while the control keys are held.
Can anybody else think of something I'm missing? Best, TB
Nevermind. I seem to remember a tempo or osc speed -based slicing of the samples. Maybe that was just in my head. Anyway, I don't want or care about that :)
Thanks for working on this stuff.
By the way, do you still have some rev. 1 hardware for sale? My buddy was thinking about hopping on the WTAP bandwagon.
@glitched -- I have about 20 units left or so. Not too many with SRAM left. @blue_lu -- there will be one more firmware rev for the version 1.01 hardware. After that, there will be new hardware which is what I focus on writing code for. The two will need slightly different firmware because of the hardware changes, but I am not forseeing back-porting new features being a problem, if enough clamoring happens.
*Start/loop/endpoint adjust Just to be totally clear (though you can probably see this in the rough source code mods that I sent you), I think WRT the loop adjust, it should be loop *duration* adjust.
*Subtractive summing (my idea, nobody asked, but I think it'd sound cool) and maybe absolute value conversion Hey this might be cool if you had the exact same sample in both banks, and then moved the start point of one of them a few samples later, and then subtractively summed the output - might get some weird phasing effect maybe?? Of course, this will require you to implement yet another feature: copy sample from one bank to the other. Maybe??
In a somewhat related thought, I was wondering if their could be an option to trigger the Record function based on audio input exceeding a threshold level. Then if you were sampling something that you easily reproduce (say from a drum machine or something), then it would be easy to get pretty much the exact same sample recorded in each bank, without relying on manually triggering Record with a key press at identical points each time...
*Parameter adjustment while the control keys are held. Yes, definitely - only thing I can think of to be careful of here is that some of the key combinations are already a bit tricky to hold down with one hand - so if using the other hand to adjust the pot while holding down 2 or 3 keys.... might be a little awkward (but probably not a big deal either).
Finally, just curious - 20 units left out of how many total?
"In a somewhat related thought, I was wondering if their could be an option to trigger the Record function based on audio input exceeding a threshold level. Then if you were sampling something that you easily reproduce (say from a drum machine or something), then it would be easy to get pretty much the exact same sample recorded in each bank, without relying on manually triggering Record with a key press at identical points each time..."
Awesome idea. Again, a feature on my old prophet 2002.
One thing I have been doing as a work around is to make a two tracks in cubase, one midi on audio. The midi track has the start and stop midi commands for the sampler and then I just simple insert whatever I want to loop in the audio track. I hit play and the start and stop are started remotely..
Hey all -- @Altitude -- that's a smart way to get WTPA to reproduce sampling behavior on audio tracks -- I did a similar thing once with my MPC. @Dnigrin -- Copying samples to the other bank is a good idea, and easy. And you're right, would help weird recombination sound cool. And would allow you play power chords with your sample :-) Done! A threshold-based recording is a good idea and would be possible, but perhaps weird. There are a lot of gray areas involved -- like how to set threshold level, like the fact that the ADC would need to keep running which would mean you couldn't use the control pot, like when do you decide STOP recording and is that adjustable, etc.
I guess my impression with that would be to keep it simple. Maybe the threshold is fixed, we don't worry about parameter adjustment while waiting to trigger (until the next hardware rev anyway), and the recording would stop and start looping (or playing once) as soon as the threshold was reached again after a period of relatively low-level signal. The idea might be to catch a phrase. So maybe:
Wait until TRIGGER threshold is exceeded. Begin recording. Wait until signal remains below RE-TRIGGER ENABLE threshold for (x) samples Wait until TRIGGER threshold is exceeded again. Stop recording, begin playback.
That sound about right? Theoretically all of those parameters are tweakable but at this point it's getting silly with the button presses, as people have pointed out, and I'd like to keep the thing as easy to use in caveman mode as possible. Might want to leave those tweaks all for the 4-channel "Hotel Lobby" behemoth that I'll likely never make :-) Let me know, and thanks again for all the suggestions. You guys sure do know how to keep a guy in for the weekend. Best, TB
Only thing I don't understand is why you wait till TRIGGER threshold is exceeded again, after the signal remains below the threshold for X samples, to stop recording? I would've expected it to stop recording immediately after the signal was below the threshold for X samples...