2 Comments

four sixty

legasizing

midi2osc, as mentioned in the last post, got some updates which made its name obsolete, particularly the ability to send MIDI and receive OSC, so it has now been renamed OSCII-bot. Other mildly interesting updates:

• OSX version
• Can load multiple scripts, which run independently but can share hardware
• Better string syntax (normal quotes rather than silly {} etc), user strings identified by values 0..1023
• Better string manipulation APIs (sprintf(), strcpy(), match(), etc).
• match() and oscmatch(), which can be used for simple regular expressions with the ability to extract values
• Ability to detect stale devices and reopen them
• Scripts can output text to the newly resizeable console, including basic terminal emualtion (\r, and \33[2J for clear)
• Vastly improved icon

I'll probably get around to putting it on cockos.com soon enough, but for now a new build is here. Read the readme.txt before using for instructions.

The thing I'm most excited about, in this, is the creation of eel_strings.h, which is a framework for extending EEL2 (the scripting engine that powers JSFX, for one) to add string support. Adding support for strings to JSFX will be pretty straightforward, so we'll likely be doing that in the next few weeks. Fun stuff. Very few things are as satisfying as making fun programming languages to use...

8 Comments

more cold
newy warm

quick defrost

nonsensetup 457 tester

Making installers and web pages is too much of a pain for a small project, so:

Here's another project, this one took less than 24 hours to make. It's a little win32 program called "midi2osc" (license: GPL, binary included, code requires WDL to compile), and it simply listens to any number of MIDI devices, and broadcasts to any number of destinations via OSC-over-UDP.

MIDI and OSC use completely different types of encoding -- MIDI consists of 1-3 byte sequences (excluding sysex), and OSC is encoded as a string and any number of values (strings, floats, integers, whatever). It would be very easy to make a simplistic conversion of every MIDI event, such as 90 53 7f being converted to "/note/on/53" with an integer value of 7f, and so on. This would be useful, but also might be somewhat limited.

In order to make this as useful as possible, I made it use EEL2 to enable user scripting of events. EEL2 is a fast scripting engine designed for floating point computation, that was originally developed as part of Nullsoft AVS, and evolved as part of our Jesusonic/JSFX code. EEL2 compiles extremely quickly to native code, and can have context that is used by code running in multiple threads simultaneously.

For this project the EEL2 syntax was extended slightly, via the use of a preprocessor, so that you can specify format strings for OSC. For example, you can tell REAPER to set a track's volume via:

    oscfmt0 = trackindex;
    oscsend(destination, { "/track/%.0f/volume" }, 0.5);

Internally, { xyz } is stored to a string table and inserted as a magic number which refers to that string table entry. It is cheap, but it works.

Other than that pretty much everything else was a matter of copying and pasting some tedious bits (win32 MIDI device input, OSC message construction and bundling) and writing small bits of glue.

Since writing this, I've found myself fixing a lot of small OSC issues in REAPER. I always tell people how using the thing you make is very important -- I should update that to include the necessity of having good test environments (plural).

Why did I make this? My Zoom R24. This is a great device, but the Windows 7/64 driver has some issues. Particularly:

• If the MIDI input device of the R24 is not opened, audio playback is not reliable. This includes when listening to Winamp or watching YouTube. So basically, for this thing to be useful, I need something to keep hitting the MIDI device constantly. So for you Zoom R24 win64 users who have this problem, midi2osc might be able to fix your problems.
• If REAPER crashes or is otherwise debugged with the MIDI device open, the process hangs and it's a pain to continue. Moving the MIDI control to a separate process that can run in the system tray = win.
• (not midi2osc related): I wish the drum pads would send MIDI too... *ahem*

As a result of this, the midi2osc.cfg that comes in the .zip represents basic support for the R24:

// @input lines:
// usage: @input devicenameforcode "substring match" [skip]
// can use any number of inputs. devicenameforcode must be unique, if you specify multiple @input lines
// with common devicenameforcode, it will use the first successful line and ignore subsequent lines with that name
// you can use any number of devices, too

@input r24 "ZOOM R"


// @output lines
// usage: @output devicenameforcode "127.0.0.1:8000" [maxpacketsize] [sleepamt]
// maxpacketsize is 1024 by default, can lower or raise depending on network considerations
// sleepamt is 10 by default, sleeps for this many milliseconds after each packet. can be 0 for no sleep.

@output localhost "127.0.0.1:8000"

@init

// called at init-time
destdevice = localhost; // can also be -1 for broadcast

// 0= simplistic /track/x/volume, /master/volume
// 1= /r24/rawfaderXX (00-09)
// 2= /action/XY/cc/soft (tracks 1-8), master goes to /r24/rawfader09
fader_mode=2;

@timer

// called around 100Hz, after each block of @msg

@msg

// special variables:
// time (seconds)
// msg1, msg2, msg3 (midi message bytes)
// msgdev == r24  // can check which device, if we care

(msg1&0xf0) == 0xe0 ? (

  // using this to learn for monitoring fx, rather than master track
  fader_mode > 0 ? (
     fmtstr = { f/r24/rawfader%02.0f }; // raw fader
     oscfmt0 = (msg1&0xf)+1;

     fader_mode > 1 && oscfmt0 != 9 ? (
       fmtstr = { f/action/%.0f/cc/soft }; // this is soft-takeover, track 01-08 volume
       oscfmt0 = ((oscfmt0-1) * 8) + 20;
     );

     val=(msg2 + (msg3*128))/16383;
     val=val^0.75;
     oscsend(destdevice,fmtstr,val);
  ) : (
     fmtstr = (msg1&0xf) == 8 ? { f/master/volume } : { "f/track/%.0f/volume"};
     oscfmt0 = (msg1&0xf)+1;
     oscsend(destdevice,fmtstr,(msg2 + (msg3*128))/16383);
  );
);

msg1 == 0x90 ? (
  msg2 == 0x5b ? oscsend(destdevice, { b/rewind }, msg3>64);
  msg2 == 0x5c ? oscsend(destdevice, { b/forward }, msg3>64);

  msg3>64 ? (
    oscfmt0 = (msg2&7) + 1;

    msg2 < 8 ?  oscsend(destdevice, { t/track/%.0f/recarm/toggle }, 0) :
      msg2 < 16 ?  oscsend(destdevice, { t/track/%.0f/solo/toggle }, 0) :
        msg2 < 24 ?  oscsend(destdevice, { t/track/%.0f/mute/toggle }, 0) : 
    (
      msg2 == 0x5e ? oscsend(destdevice, { b/play }, 1);
      msg2 == 0x5d ? oscsend(destdevice, { b/stop }, 1);
      msg2 == 0x5f ? oscsend(destdevice, { b/record }, 1);
    )
  );
);

msg1 == 0xb0 ? (
  msg2 == 0x3c ? (
    oscsend(destdevice, { f/action/992/cc/relative }, ((msg3&0x40) ? -1 : 1));
  );

);

The 9th fader sends "/r24/rawfader09" because I have that OSC string mapped (with soft-takeover) to a volume plug-in in my monitoring FX chain.

6 Comments

somethingnew

somenonsense

Today I wrote a proof of concept program called "mikmod2rpp" (requires libmikmod and WDL). Most of the code in there is based on the Gravis Ultrasound driver for MikMod, but instead of uploading the sample data to a soundcard, it writes it to .wav files, and instead of playing the samples on the soundcard, it writes a REAPER project file (RPP). It is not perfect, does many things wrong, but it's somewhat usable.

Here are a couple of test projects (which include the mod/xm as well as the converted files): spathi.mod (from SC2), and resistance_is_futile.xm.

In case there's any question, it turns out the tracker format is incredibly efficient for both editing and playback... compared to a DAW.

3 Comments

ezequiel - 1 -- [7:44]
ezequiel - 2 -- [5:13]
ezequiel - 3 -- [5:15]
ezequiel - 4 -- [11:13]
ezequiel - 5 -- [3:31]
ezequiel - 6 -- [5:06]
ezequiel - 7 -- [7:24]
ezequiel - 8 -- [12:08]
ezequiel - 9 -- [9:11]
ezequiel - 10 -- [21:54]
ezequiel - 11 -- [4:06]
ezequiel - 12 -- [3:37]

Digging the album "Recreation" by Papier Tigre. Here's a pretty good live video (bad mix from one side of the stage, but, it's still quite listenable IMO):

Comment...

Comment...

(youtube link)

Comment...

here is the m

burps of joy

as it exits

no do overs

dont lose it

for some reason i do not care

forcing the eight

part 18 of 37
showering
showering with randomgermanvox

brerp

a little more wankage, reliving my highschool days
start/stop

Recordings:

kawha

7 Comments

alldayattendant

start/stop gfx

Recordings:

chillstache

1 Comment

wo dat

bag of nuts

I'm a fan of bicycling, and the launch of Citi Bike here in New York is something I am still quite excited about! While the launch has had its share of glitches, it's really shaping up. Their blog has been giving daily statistics, and I thought I'd put them in a spreadsheet to see if anything interesting could be made. I've made the spreadsheet public in Google Docs in case anybody wants to do some additional analysis.

Some initial comments on the data:

• The average speed is calculated based on the total mileage counter, trip count, and average trip duration. After the first few days (whose data is a bit all over the place), it settles in at about 7.4-7.5 MPH. Do we think that their distance calculation is A) as the bird flies, B) bird-distance * cityadjustmentfactor, or C) they route most likely route in google maps? Probably safe to rule out C, and given the top speed of these things is probably around 15MPH, I'd say it's probably B (some 1.3x cityadjustmentfactor, or something).
• If we assume that the last 5 days worth of data on day and week passes hold steady (I know, unlikely, as factors such as season, initial buzz, conversion to annual members, and so on will affect things greatly), these will bring in $9.3 million and $2.2 million per year respectively.
• If annual members top out at 80,000 (a little under twice what it is now, I would say this is very conservative), that'll be around $7.6 million per year.
• It becomes apparent why they are called "Citibike" and also have Mastercard logos on them (as they ponied up something like $41 million and $6 million respectively -- I wonder if this is one time or per year).
• Hopefully annual membership will continue to grow well past 80,000, though, and presumably there will be extra revenue from late fees...
• I wonder what their operating budget is...
• OK discussions of money are sort of a bummer (not because of whether this is feasible or not, but just because talking about money makes me uncomfortable): the average trip length of 2-3 miles is pleasing.. 2 miles in a long way in Manhattan, glad to see people are making good use of the bikes!

On an unrelated-to-citibike-data-note, it is also humbling to see that even when CitiBikes are being used in record numbers, they are still far, far outnumbered by normal bicycles. Anyhoo..

If anybody makes any interesting graphs or correlations or extrapolations with that data, post 'em (or links) in the comments...

5 Comments

hello exp

bringing back the power pc

siebzehn

the worse sixth

untz

still wtf

433 test wonkerings

no end in sight

tangent

a day ahead

Using stuff coming in the next release (though it is not obvious what that stuff is, aside from webm encoding, due to the nature of it, but I didn't play it nearly this well live, and of course it only took a handful of minutes of recording and couple hours to do start to finish):


2 Comments

derpin

lesrinsp

wok1

transcoastal goodies

2 Comments

wasssatz

hhhhhbbdy

herr_grunig - 1 -- [4:39]
herr_grunig - 2 -- [3:40]
herr_grunig - 3 -- [4:59]
herr_grunig - 4 -- [2:54]

hello nemo

sssstretchy

stretchystretch

bow and dl4
bow and dl4 nude

alittleditty fjords

louie - 1 -- [67:37]
louie - 2 -- [3:43]

dodeedo pt 2

1 Comment

Comment...

Comment...