Jump to content

Jidis

Members
  • Posts

    838
  • Joined

  • Last visited

Posts posted by Jidis

  1. 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).     

  2. Simone,

    No, there's Macs all over the place here, but they're mostly older (G4 and below). I even stuck to OS9 for quite a while after X came out. Been meaning to set up an OSX86 partition for a while just to look at it, as one whole half of my family runs Macs. (...hope nobody's offended by the mention of OSX86 ;)).

    PS- Get that Sahira close-up back! This one's great too, but that other one was awesome. What is she on in this new one, a roof?

    And for anyone interested in the SysEx eavesdropping concept:

    I got a solid config last night on an XP machine running Ox/Yoke along with an Alesis SR-16 and an SR-16 editor utility demo. Everything seemed to function properly in both directions. Only thing I'd like to knock out now is some redundant display data in the Ox monitors. For instance, a big chunk (79 bytes?) of SysEx containing all the drumset parameters was sent to the Alesis. I kept the Input & Output monitors both open (one covers the top half of the screen, the other the bottom). I get two identical 79 byte chunks in each of the windows, but AFAIK, nothing involved is set on a "thru" mode or anything, so I can't figure why both monitors are showing the same exact stuff with just outgoing messages. I'm figuring most of it comes down to the fact that an extra in/out pair is now being used for the virtual ports, so I'm seeing a list of the activity going both ways on all ports. I need to look into filtering stuff out of the monitor windows, without changing the patching in that MIDI-Ox "device" panel.

    BTW, I think the device setup was something like: Yoke set for two virtual ports. MIDI-Ox port mapping was- Hardware Out included Yoke input 1 (and MIDI-Ox Events or something). Yoke Out 2 included the Hardware Input and the Ox Events. Then my editor app was set to send MIDI to Yoke port1 and receive from Yoke2. I tried to clear the Ox map box of anything other than those few things.

    Still need to check it on my desired 98SE SCSI sampler rig, but nothing seemed to get corrupted or anything between the drum machine and XP. I think I've been running that previous MIDI-Ox (v.6.5x?).

    That system looks to be a big help for anyone who may be considering making a MIOS app to edit a module via SysEx, or who just wants to study a module's SysEx data structure. The SysEx docs for much stuff I've found have been sort of brief and not as well organized as the owner's manuals. Looking at the block of drumset data I used, I could see exactly where each parameter sat in the sequence by changing one on the machine and re-sending the whole block. It also makes the mixed streams of full/nibblized bytes a lot easier to sort through, and with an existing software editor, you can watch the whole conversation between the host/module during handshaking crap. You can also easily send your own copied and edited test data from the SysEx scratchpad while you examine the monitors.

    Check it out if you haven't (and figure out how to clean my monitor displays up for me ;D)

    George

  3. Seppoman,

    Much thanks! Funny, I was just headed back in here to report that it looks like an Ox/Yoke combo might do it. I got it (MIDI-Ox) displaying messages sent to and returned from the sampler (which was using Yoke ports), and had them linked to the real ports in MIDI-Ox's device boxes.

    The only trouble was that the editor app for the sampler wasn't getting SysEx back via Ox/Yoke. It went out to the sampler OK.

    I must admit Ox's routing panel has always confused me. There's a bunch of extra stuff in it that I don't get. I'll play around and try your "dual-Ox" suggestion when I get to the studio machine.

    Take Care

  4. Hey :)

    Yeah, I've been using MIDI-Ox for that stuff. That's what I watched the data on when I setup that patchbay thing.

    The problem is, that when the bi-directional hookup is happening between the sampler & computer (while the editor app is running), MIDI-Ox no longer has available ports to use (or vice-versa). If the sampler was a plug or application, I'd be set with MIDIYoke. I need a way to pass the data to and from a virtual (& split-able) port, and then connect the virtual ports to my real ones.

    Take Care,

    George   

  5. Hi,

    Does anyone know if there's any relatively easy way of watching SysEx activity between the computer and a connected device?

    I've got a sampler hooked to the computer via standard 1x1 built-in MIDI and am running an editor on the host. I'd like to open MIDI-Ox or something in the background and view the transmissions across the i/o ports.

    I've checked into MIDIYoke, but it seems to mainly allow extra patching between software apps (not externals). I just want to grab the in/out streams, split them to MIDI-Ox, and send them on their way.

    I set up a MIDI patchbay as a splitter and a laptop to watch the stream, but I could only watch the "sent" messages, plus it was a PITA mess of junk. I can bring a multi-port interface home if that would work.

    There's got to be a software workaround???

    Thanks!

    George

  6. As one who is always willing to help with stuff that I know about, I don't generally presume that people are going to be as downright nasty as many that I've encountered on this list.

    Gene,

    I can totally relate to the first part and WRT the second, believe me, they're usually not (I've been here a while). It's hard to understand, without having been around for the start of the whole bluelantern fiasco, what it did/does to the spirit here. You have to realize that after explaining/asking him to stop, and trying to make him stop, a lot of the energy might have hit sort of a dead end and it's probably not wise to poke around in it (which, I guess you found out).

    Hope you get it sorted out, and apologies to TK and all here for the headaches this guy has caused (.. -->BL, not you Gene ;)).

    George

  7. my answer is simple: f*** the 'standard' and do what works best for the songs

    That's sort of what someone over there mentioned. Said he usually sees the "base" parts like kick/snare/hats in the same (General MIDI) map locations, and everything else might be who knows where. I can deal with that too, I just don't want patches where every time you change one, you have to go skimming through all the note numbers to figure out where everything is. It would be more of a PITA with non-keyboard controllers and drum machines.

    Still don't know what approach to take for the multiple snares and kicks that some of those machines had.... and the polyphony thing ...... and the dynamics/velocity thing  ....damn.

    George

    PS- Some of those old sounds are fascinating. I was building a patch last night with the E-mu Drumulator sounds ( http://www.vintagesynth.com/emu/drumulator.shtml ) Man, that thing had some "grit". 8-bit crunch. The open high hat will make your teeth hurt.

  8. I put a post in the KVR sampler forum yesterday about some drum patches I'm trying to make, and some map/velocity/voicing issues:

    http://www.kvraudio.com/forum/viewtopic.php?t=205019

    There are only a couple replies as of yet, but a bunch of reads. I'm hoping for some input from people who have dealt with an assortment of MIDI gear and drum patches, who may have observed some standards or similarities. I figure there's a bunch of you in here too, so if you can offer any tips there it would be great.

    I'll probably decide on something and start loading up patches over the next day or so.

    Thanks!

    George

  9. I'm guessing many of you guys have seen or done this before. If I've seen it, I must have forgotten about it. Looks really effective/easy, and centers the board in the hood, as opposed to a regular 90 degree PCB mount or something. 

    - Of course it involves a double-sided board, but it need not be an overly complicated one. :)

    BetweenPins.jpg

    There's a Centronic-50 on the other end of that adapter which is done the same way.

    George

  10. Sasha,

    If it's any help, I run cables that are about that long on a box or two (with MIOSStudio), but I guess there's a million other factors like cable type,etc.

    I'd try to eliminate driver/host issues first, if you can run it on a different machine or OS. I've got a MOTU box here that works fine on 98, but will corrupt SysEx streams using its "so called" 2K/XP driver.

    Hope you get it working,

    George

  11. Echopraxia

    Maybe not the same scenario, but I seem to recall that using more DOUT SRs than the app is set to utilize, will sort of duplicate the 8 pins across the remaining ones (for instance: the 9th LED will light along with light #1, 10 with 2,etc.). If you're getting more than one pin lit on each register, then you may have a problem. Otherwise, changing your app settings to see a higher number of DOUTs should work.

    Hope that helps (and someone please correct it if it's wrong ;))

    George

  12. Jidis, what is drum finish roller?

    A big, heavy piece of crap that I built and used for about a day. ;D

    It actually spins drum shells too. The xerox machine roller part just squashes the sheets of plastic finish onto the shells (with contact adhesive). If you use a small hand roller, you tend to get air bubbles in the plastic. It worked OK, but I haven't needed it much.

    front.jpg

    Take Care (and please post pics if you do any more "spin grinding").

    George

  13. Sasha,

    I use a long version for my drum finish roller. ;D

    roller2.jpg

    I think it may have actually been the "pickup wheel" from a copy machine though.

    Keep up the good work on the knob burning. That dark one is resembling the Alesis 3630 knobs I'm fond of. (burn it down any more and you may be left with dust though ;))

    George

  14. Well Justin (one of the two programmers) finally commented on it yesterday, but just said to check my soundcard's latency settings as it was directly tied to MIDI output precision, and that I should try to get the buffer down in the 3-6ms range (ouch). I bottomed out the buffer and it did seem to get "better", but if I'm not playing softsynths in realtime or anything I try to keep it up a couple notches.

    Still not sure what the deal is or if he plans to fix it, but Nuendo is fine on the same machines.

    George 

  15. Stryd,

    Have you tried it by chance? There's a reply in there now by someone using the same machine I was feeding on one computer (an SR-16), and they seem to imply that something is wrong on my end.  ???

    It's no big deal I guess, but geez that sounds like crap. There are a couple mp3's in an attachment over in that post, and they're actually some of the "better sounding" results. ;D

    George

  16. FYI the wavetable port is treated the same way as external midi.

    I figured something like that. VSTi's are definitely OK. I actually tried a session yesterday with a VSTi track and a duplicate track sending to an outboard module and the module timing sounded like s**t, but the virtual instrument was fine.

    What I don't get is how nobody in that whole forum seems to notice or care that it's that messed up. Feel like I'm in the Twilight Zone or something. Another MIDI timing related bug post showed up a week later involving plug-in delay compensation and was immediately acknowledged there. This thing would seem to make using outboard MIDI totally impossible. Guess I'll just keep quiet and wait.

    BTW- Reaper's sequencer now has swing, input quantize and some other junk added in. It's interesting to watch its progress over there (even if the hardware out is mangled ;D)

    Thanks!

    George

  17. Thanks Stryd for the tip on Temper. Hadn't heard of it before then. I'm probably going to stick with trying to make sense of Reaper for the time being, but will be watching it. I'm having enough trouble being a Nuendohead for so long.

    If anyone wants to take a crack at this Reaper bug to assure me that I haven't lost my mind, I'd appreciate it:

    http://www.cockos.com/forum/showthread.php?t=14327

    As easy as it was to hit, all I can figure is that somehow there's nobody in there trying to use any outboard gear (if that's where the timing bug lies). Figure there's plenty of it in here.  8)

    Take Care,

    George

    PS-They've put out a hardcopy of the Reaper manual. There's a link over in the forum somewhere.

  18. Is it faesible to install an OS on to compact flash like this? I remember reading that they only have a certain amount of read/rights before they start oing corrupt and become unusable.

    That was a tip given to me in here I believe. I can dig the thread up later if you can't find it. With my setup, the actual speed of the CF being used as an IDE drive was quite horrible for some reason. Transfer speed and (more importantly) CPU usage were both pretty bad, but it was indeed "dead quiet".

    Take Care,

    George

×
×
  • Create New...