This sucks. (SysEx -long)

[Jidis]

I was all excited about playing around with tweaking parameters in these Peavey samplers and maybe getting some of the ones I needed into a small remote of some sort. Turns out, while pretty much every parameter in the machine can be accessed remotely over MIDI or SCSI, the damn thing has to send and receive entire "object blocks" for any single parameter. For instance, everything within any of the "tone" menus are wrapped into a "tone object", so just to change the sustain length (one 7 bit parameter) for a single tone, you'd be sending over a whole block of more than a couple hundred bytes of "tone object" data including everything from ASCII name crap to filters and volume settings. Then, to make matters worse, doing it correctly probably involves requesting and receiving this same giant block of junk from the sampler beforehand, to insure that all the other parameters remain consistent. Worse yet, every damn thing in the block is nibblized, so you've got two bytes hogging up bandwidth for every one byte number and most of the block is just wasted on zeros. And for the "icing on the cake", consider that the whole point of editing tone or wave parameters in an outboard module usually involves listening and evaluating the changes as you make them.... so now you've got note/sequence data trying to use the stream while all this other crap is in it. Oh wait.... then of course with continuous controller messages changing the parameters, you've got a flood of blocks going out for every single value between the start and end of the control movement!

They do give you the SysEx equivalents to trigger any of the front panel button signals, so that would avoid all the block transfers, but they don't give any means of outputting the display status, so pressing buttons remotely would only work if you were able to watch the actual LCD on the rack unit to see where the cursor was. I guess if I was Thorsten I could grab some data lines to the LCD and route them externally, but I'm obviously not. Then again, he could probably figure a way to read/write directly to those individual parameter bytes anyway (...it must be nice).

Is that how most heavier sound modules are set up for external control, or do you usually get direct access to all the parameters?

Also, I don't mean to knock Peavey for this. They did make all this info easily accessible. It shipped with the samplers on paper, and is also available as PDF. Plus, they backed Matt Isaacson, who should have been awarded a Nobel Peace Prize or something for attempting to bring SMDI to the sampler world.

Sorry for the long ramble, just sort of disappointed. Guess I can make a control for this MIDIVerbIII (...what's that got like ten parameters or something? ;D).

George

PS- If anyone wants to answer this one: In the SysEx manual for the SP, it breaks down the individual contents of some of the "object block" structs. It defines the struct before listing the contents, but then you'll see the struct definition show up randomly within the list of contents.

It's here if you want to see it:  http://www.spsamplesite.com/HTMLobj-557/DPM_SP_SysEx_Data.pdf

If you check the "Tone" object starting on page 19, you'll see the definition at the top of the list on p.20, but then you'll see it again under "envelope2 sustain time" about midway down that page, and one or two more times on the next couple pages. What's the deal on that? Counting bytes through the list shows that it doesn't affect anything (like a commented line).     

[stryd_one]

Ahhh sysex implementations. That one's a pearler. The downsides are obvious (having to send/recieve full blocks and do manual bounds checking - I'm guessing they were low on program space) but I guess it's a big upside that they included the structs! I think those extra lines are a typo, you can cut them out.

This implementation is suitable for librarian functions but not for live editing, sorry dude :(

[Doug Wellington]

Wow!  Memory lane!  I have two Peavey SP units in my rack still...  (And two SX-II samplers.)  I'm the guy that wrote the first SP floppy disk duplicator that ran under DOS...  :)  (Sheesh, when WAS that???  1991?)  Man, I might have to plug those things in again...

[Jidis]

Cool!!  So there was a "pre-SPDISK" floppy app? I haven't been doing much big stuff on floppy lately. I wish there was better outside support for the hard disk format though. I think ChickenSys is supposed to support the SP, but it doesn't look promising.

Stryd- Thanks! I thought maybe that definition line jumped out of somebody's copy/paste buffer a few too many times. You know, they actually mention in the SysEx docs that there may be additions to the SysEx message system (I guess the SP's) which would allow for individual parameter access. Seems a waste that, as that whole object thing is just a sequential list of nibblized parameter values, they couldn't have just added an extra ID byte to that chunk of SysEx header crap that would tell it how far into the string of parameters it needed to go to get to one particular item (unless I'm oversimplifying it, and the machine itself can only access them the other way). Maybe had there been more Doug Wellingtons out there when it was current, they would have kept working on it. I didn't get one until the past year or two and have been kicking myself for it. It pretty much blew the crap out of everything that was around in it's day, for less money, yet nobody bought it.

Doug- Are you "regular" SP? I bought a dead battery damaged SP+ first and fixed it, then grabbed an old SP for home a few months ago. Never needed the SX, as I do all SMDI. Check that SMDIXferGUI program if you haven't. I stuck it in the files section of the Yahoo DPM group, but I found it on the net anyway. It's really nice.

That "plus" looks really promising inside BTW. Same size board, but they gained some space by switching most of the guts to surface mount stuff, so there's this whole bank of sockets for who knows what, an internal SCSI header and some power headers (even though there isn't much space for internal storage devices), and socketed program memory. The plus has double the SP program memory, but it looks like they both have a pair of the same chips (roughly the SP memory size) in them, then the plus has a couple additional larger memory chips, so I don't know if you can bump up the regular one (its program memory was a bit small for drum patches).

Take Care,

George

[stryd_one]

(unless I'm oversimplifying it, and the machine itself can only access them the other way)

Maybe had there been more Doug Wellingtons out there when it was current, they would have kept working on it.

It's possible that there was a lack of effort I guess...also possible that there are hardware memory access limitations but ahhh... unlikely. They aren't *that* old ;) I think it's more likely that they were fresh outta space/milking it for all they could. Keep in mind that when these things were new, electronic music had not yet developed to such a great degree the current trend of using realtime modulation, as such, realtime modulation capablitities were not as high a priority. You generally find only the most basic of exceptions: Velocity (often hardwired to volume) and Pitchbend (Guess where that's usually hardwired. heheh). Anything else is kinda a bonus ;)

FWIW, there are other issues aside from how fast you can get the data in there too... The processors in these things are often incapable of fast updates to the sound. My akai s2000 (a bit newer than your peavey I think. BTW, a badly underrated box) allows direct access to the parameters via sysex, including fast sysex transmitted via SCSI-2 cables from a PC editor (MESA comes from akai and Millennium is 3rd-party and 1000*better) but there's still a noticable latency (in the 10's of ms). Fortunately you can map the modwheel or pitchwheel to a great deal of parameters, and that's nice and smooth, but it goes to show that even for a box newer and more powerful than the peavey, realtime modulation is pushing it, direct sysex or otherwise.

[Jidis]

but there's still a noticable latency (in the 10's of ms).

I remember that from running Opcode's Galaxy with my K2000, but never pinpointed it to MIDI or the sampler's CPU (probably some of each). The main parameters I'm trying to tweak on this Peavey are pretty simple, and edit very smoothly from the inc/dec buttons, but they may clog if you were to make drastic jumps in the values (like text entry editing). There's a really nice discontinued editor called SP Remote by Relativity Systems, which is now freeware. IIRC, edits with that weren't bad, and I guess it's doing all that same "giant block read/write" junk. I think the worst (or impossible) part would be trying to manage enough of that activity from a MIOS app or something.

If that Peavey ever shows up in Oz for cheap, it's pretty unique (reads Akai S1000 format, has built-in SCSI, has 8-30pin Mac SIMM slots and is only 1U rack). I think the SPRemote app was over a hundred bucks back then. I've seen the old SP go for $12 here on eBay. Twenty something is almost an average. Mine was $30.

George