Sculpting beats in real time

Hi all,

I have this thing that I keep running into while programming beats on my MPC. And I am wondering how you guys think about this. I'll explain what's the 'problem'.

I like to sculp my beats in realtime while the sequencer is running. This is how I used to build my beats in Logic. A matrix editor and a list editor next to eachoter, just like in the MPC actually. This allows you to optimize your timing while you are constantly monitoring the result in your loop. This keeps the flow going.
Because of RSI-like problems, two years ago, I decided to buy the MPC as dedicated hardware so I could use the notorious mouse a little less. Well a lot less actually. But it seems that I am forced to go back to the computer again because of some limitations in the MPC.

Unfortunately the MPC's sequencer is programmed in a way that doesn't allow you to edit about anything in realtime, when the sequencer is running that is, as far as I know. You always have to stop to move anything I mean, when you create more alternative groovy beats, like I do, or dance grooves for that matter it's almost a must to keep the energy of the beat in the studio while you are working on it. This allows you to sculpt a beat until it feels right.

Of course there is the TC window that does a pretty fair job here, but there are two problems with the TC window. One, the TC window does not work for notes that are just recorded (sequencer is playing, press overdub+play, record some notes, press overdub, keep playing, press TC+window, the window appears but has no effect). Bu t the second and most frustrating thing is that the settings in the time and pad/note fields are not monitored and adjustable in real time. You can only monitor the time shift function for all notes and for the complete track while the sequence is playing, no matter what your settings in the time and pad fiels are. The timespan and selected pad settings are only processed after pressing STOP and DO IT(F6). This is so outdated. We are living in the realtime era now! This is more like a process of technical trial and error and it sucks basically. Of course you'll get better in it when practacing a lot but I don't understand why the time and pad settings aren't monitored in realtime. This alone would make the proces of TC so much more musical from my point of view. Now you have to think what would be a nice setting. Stop the beat. Adjust the setting. Process. Play and check. No, that's not quite it. Listen. Think again....
Well, if you'd make the time and pad settings available in realtime it would only be a matter of listening until it feels right and that is basically what you are trying to accomplish in the end anyway. Therefor I say at least adjust the way the TC window operates so all of us producers can listen to what we are doing without being forced to stop the groove every single time.

Anyone?

Send this to [email protected] please.

Hi Rob, Yeah I will. Thanks.

yeah ... agree on everythin ... send it there please ...

bleepfreak wrote:Hi Rob, Yeah I will. Thanks.

I understand your need. I also understand why the time 'window' is not implemented in the TC page. It's much easier (and probably more safe) to simly add a time offset to all the events of a given track.

The other issue is the fact that you can't edit a track in Step Edit while playing. That too is a big one on my list as well. Should be possible, with not too much work either. The biggest amount of work is GUI stuff, I guess.

Yeah, I understand what you mean with easier/saver. I think I have been able to develop a pretty clear vision on how the MPC sequencer operates, technically spoken, in the last two years. Mainly because of the bugs I ran into and reported. I think, so don't hold me to it cause I might be wrong in the end , the MPC uses two different kind of buffers one for steady playback and offline editing. Each track has one of these. It is where the data is stored into. And there also is a dynamic buffer for recording stuff onto the selected track. This one only exists for the selected track. The recording buffer is saved into the playback buffer after pressing stop. You can even see this happen in step / seq edit mode. New notes only appear in the list aftter pressing stop. When you press play, or when you select a new track during playback, the playback buffer from the selected track is read into the recording buffer for recording new stuff. The step editor does not work for this dynamic recording buffer, only for the playback buffer. So there you have what I think is the problem with the availabillity for step editing in real time.

I totally agree, and it is way on top of my wishlist too, that it would be best if the step editor would be made available completely during playback as well, but I guess that would imply some reprogramming in the basic principle of the recording/playback engine instead of just some gui changes. I for sure hope that they will be willing to take this effort, but speaking about safe...
That is actually why I thought it would be easier as a first step to make the TC window's time and note fields available in realtime since the TC window is already partly available during playback... don't know what the programming implications this would imply though.

Anyways I am working on an email to AKAI right now, but I want to get it just right for all of us. So I will be sending it only after a few days so we can share some more thoughts on this one, because I think it is pretty important.

Thanks for your input.

U should ask akai for a job

U blew my mind with that buffer shiiii...

I now bow down to your natural knowlege of the beast....

Hi Bleep, you could be right about the double buffers. Haven't looked into that much really. Thinking about it, having separate buffers for editing and playback per track sounds like a bit too much for my taste. You would have to copy the edit track to the playback track all the time, and especially with long tracks holding lots of data, this would take a long time, and reduce the memory by half.

And if we would indeed have a separate edit buffer, why protect it during play? It's all guessing of course, but I was hoping for a single buffer per track. And instead of protecting it in the Edit pages, changes should be allowed while playing by locking (part of) the buffer for a short moment. That was my 'not much work' idea.

I do agree with the record buffer though. Your description sounds very much like my own idea about it.

And then there's the single-step UNDO-SEQ feature. Yet another buffer. Just one track or all of them? You *can* change tracks while recording... Hmm.

Yeah.. well in the end it's all guessing of course.

Actually I was talking about only one recording buffer. I'm not yet sure how this would work with switching tracks though you're right about that.

One of the reasons why I came to this theory was a bug I found in OS 1.40 or 1.45. It allowed access to the next sequence page after recording, without stopping the sequencer. After switching sequences I recorded some more stuff. I never stoped playing in between. Than finally, after pressing stop the data recorded to the second sequence ended up in the right tracks but in first sequence. If the data was stored directly into the tracks this would never have happened, right? So it seems to me that the recorded data is stored to the tracks only after pressing stop. Maybe data in the record buffer is labeled with some kind of "track stamp"??? I don't know. Like to speculate about it though... Access to the next sequence page after recording without stopping is now prohibited, to avoid this situation.

And Freedom, I might do that some day, actually I am looking for a job right now. Thanks for the suggestion . Your videos were fun to watch by the way. It's nice to learn a few things about your style of music creation, which is quite different from mine...

Cheers!

Yeah, I remember that bug being discussed. Sounds like the record 'buffer' is more than just the data for the current track. It somehow remembers what data goes to which track. It doesn't remember the associated sequence though, clearly.

However, we were also talking about a double buffer per track used for playback and edit. I don't think (hope) that's the case in the MPC, meaning that getting edits done *during* play would be relatively simple patch: modify the track data while locking it quickly. While locked the playback routines cannot read it, they have to wait for the lock (in that area) to be cleared. Assuming there is some read-ahead going on, this could be doable.

Maybe this is utter BS. Guess they have to give me the sources!

the swing is sensitive for the note repeat in realtime.....so i would assume that it couldnt be that difficult to implement.

I use the swing in reatime when im doing hihats......however it only really works for those consistent hihats.

bleepfreak wrote:Hi all,

We are living in the realtime era now! This is more like a process of technical trial and error and it sucks basically.

Youre right, ive always wondered why Akai didnt implement any funky realtime midifunctions yet. Ive fooled around with the RS7000 and i was pleasently surprised that you could those funky realtime drumroll tricks, wich make certain midi notes repeat itself in a random fashion wich could be adjusted with a parameter.

It still feels like im programming beats on a pocket calculator because some midi functions are autdated. With that i mean the, note-duration and velocity edit,,, being able to select notes in between in stead of selecting in a row etc etc.

Hi Rob,

However, we were also talking about a double buffer per track
No I wasn't, I was talking about 1 per track (128 for all tracks) for playback/offline editing and 1 for recording stuff into. (129 total). My guess was that when you select a track while recording. It's data is being read into that extra one. (But unlocking / lockin is not a too crazy idea too)

I wrote:
ONE (1) for "steady playback and offline editing". Each track has ONE (1) of these. Maybe those would have been clearer??
And there also is A (1) dynamic buffer for recording stuff onto the selected track. Should have been 'tracks' plural.

Anyway, sorry for being not clear enough here. I can see why you thought I was talking about two per track now. I already didn't understand why you kept on referring to two per track.

I don't think (hope) that's the case in the MPC
...me neither see above. I think our visions are not that far ahead of eachother...

While locked the playback routines cannot read it, they have to wait for the lock (in that area) to be cleared. Assuming there is some read-ahead going on, this could be doable.
Maybe you are right. In that case I wonder why they didn't implement this already. But AKAI seem to be having a bit of a hard time adapting to the realtime era.

meaning that getting edits done *during* play would be relatively simple patch: modify the track data while locking it quickly.
Well, let's hope so. I will send in my e-mail to AKAI today with the request.

I hope I'll get a reply. Did you get a reply on the tracklength feature request? Other than "thank you I will send it thru to our R&D devision so they can look into this"? Still hoping that that one is implemented ass well. Should not be that hard either.

[i]Maybe this is utter BS. Guess they have to give me the sources! [/i}
Yeah we wish!