abox, linux and midi

[Rune Lund Sørensen]

First of all, I've been an abox devotee since the nineties - bought a license for v1.x, and spent more time geeking with virtual circuitry than was probably good for me :P

I've been fiddling with linux distributions for the past 5 years, and running abox in a linux environment has been near impossible, until the recent WINE release (1.7 I think). I get some minor bugs (due to linux's ALSA/Pulse audio system) - nothing I can't circumvent (basically, make sure that no other software is fighting over access to sound resources while running abox).

Here's my abox related problem though. I want to be able to compose sequences / pieces without dealing with complex multiplexing - i.e. classic piano-roll editing. I can run a simple sequencer alongside abox and have it send midi events (to the extend that the two programs dont start fighting about access to sound ressources) - but the ideal solution would be native midi file playback in abox.

I've tried a few VST plugins that promissed midi file playback (even tried tailoring my own with synthedit) but the bugs are countless - my synthedit plugins arbitrarily unregisters - 3rd party plugins suddenly stop working - and of course, the issue adressed by Andy elsewhere - the VST container settings does not save (at least not all) with the circuit, so I have to set tempo, playback mode and chose file all over when I reload the circuit *IF* the plugin decides to load and work. Suma Summarum: I gave up on the VST solution.

I've been fooling around with the file (text reader) object as an alternative, thinking the rectangular spreadsheet could be interpreted as a piano roll - and any basic spreadsheet program can export .csv files - the problems here are

1) linebreaks (linux) vs. linefeeds (windows) [I can fix this with a simple script - but still]
2) amount of objects - If I interpret the csv as a regular piano roll, I need a reader object for each note/key - or a fast running 'parser' solution.
3) Timing - abox is very quirky in this regard - devicing a counter that runs it's first cycle the same way it runs the subsequent ones is an intricate matter I've not yet solved in a satisfactory manner.

So...Has anybody run into similar problems? Any solutions / workarounds?

Also: can native midi file playback be implemented in future versions?

Aaaand - regarding the .csv solution, would it be possible to script a .midi to .csv conversion? (well, I know it could, but I'm not in any way familiar enough with file binary formats to even try doing that)

Anyway - Thanks for a wonderful piece of software and years of entertainment :)

Regards
-Rune

[Andy Turner]

Rune, it is good to hear from you :-)

That is excellent news about Linux WINE and ABox (sort of) working together.

A midi file player in ABox is a popular request. Would take quite a
bit of development work to implement a multi-track player. Maybe a
simple go/stop/pause input pin, then use a 'midi stream' for output.
Down-wind objects/groups could pick off what they want from the
stream. Having a player built in to ABox would get around the
otherwise intractable inter-process timing issues that plague us all.

... now that I think about it, an old-school (ver 1) VST could be
written that builds an ABox midi stream directly. The VST would do the
midi file parsing in C (or maybe even Python), then emit a midi
stream. Some advantages are 1) It could be written in C and ABox
wouldn't have to be rebuilt. 2) The 'midi stream' internal format
isn't that difficult -- I can yak about it in techy speak if anybody
is interested. 3) It might address other higher level processing
concepts that Keith has been working on. Two disadvantages are that
the plugin would work _only_ with ABox and I'd have to finally put
together that ABox/VST starter kit :-)

The csv reader/writer could indeed be used as a piano roll -- with all
the issues you've discussed. ... sometimes using two csv readers in
series (on the same file) can help (one tells the other when to
advance) ... but it's still difficult to nail down the counter
circuits. Are you taking advantage of the counter's 'reset' input ?

Seems like _somebody_ must have written a midi to csv ... try a google
on ".mid to .csv" -- I don't know if any of the apps would do what you
want ...

On the bright side, here is a hack that addresses the line feed issue
on Linux. The csv reader _should_ work OK as it exists now -- please
correct if I'm wrong. The csv writer, however, needs a couple of bytes
changed to make it issue 0xD alone (and not the 0xD 0xA it currently
does). One way to fix it is to change two lines of source code then
rebuild the program. (see
<http://code.google.com/p/analog-box/source/browse/source/OBJECTS/File/csv_writer.asm#592>)
(592) pushd 0dh ;// change 0a0dh t0 0dh
(593) mov edx, esp ;// no change
(594) invoke WriteFile,[esi].file.csvwriter.hFile,edx,1,esp,0
;// change 2 to 1
The other way to fix it involves changing the .exe file directly with
a hex editor. I'll have to peruse the .map file on my other computer,
and will post the file positions tomarrow.

Happy weekend,
--A

[Rune Lund Sørensen]

Thanks for your reply. I'll try and elaborate on some points:

>That is excellent news about Linux WINE and ABox (sort of) working together.

The only real issue is that of resource handling - FLASH in my browser crashes abox, but I can watch movies with VLC while running abox without any problems. Also, the native linux midi/score editors I tried running fried abox, while running one in wine (currently using Area Maestro) works perfectly. You might also be interrested to hear that running the 'ubuntu studio' distro (low-latency kernel) allowed me to trigger an osc in abox from my usb-midi keyboad with unnoticeable latency (external usb soundcard).

>Seems like _somebody_ must have written a midi to csv ... try a google on ".mid to .csv" -- I don't know if any of the apps would do what you want ...

I found these:
http://valentin.dasdeck.com/php/midi/mid2txt.php
http://www.archduke.org/midi/
http://www.fourmilab.ch/webtools/midicsv/

They all produce a vertical flow with each line consisting of something like [track],[timestamp],[ch#],[event type],[value 1],[value 2] - which makes sense considering the nature of midi streams. I guess an interpreter circuit could be build in abox - the hurdle would be the timer; the midi timestamps are high integers which could be a problem - my test sequence of 24 bars at 80 BPM has 130559 as 'end of file'. That, and the event types which would have to be rewritten as numerical values. I am somewhat familar with PHP and little rusty in perl, so I might try and modify some of the scripts to work better with abox + setup a demonstration circuit - watch this space (no promisses :P)

>it's still difficult to nail down the counter circuits. Are you taking advantage of the counter's 'reset' input ?

I gave up on the digital dividers long time ago for 'clockwork' purposes (I use them extensively for syncopation / polyrythm etc - especially the set/reset mode) - . I almost exclusively use digital ramps + phase controlled oscillators (either digital pulse or ramp). Other than the ability to hard reset all at once (I was amused to see that the solution I hacked my way to was suggested in a thread here), the advantage here is that I can create 'odd' subdivisions on the fly - the trade off is that my root clock must be the slowest subdivision. If I want to program a longer sequence, my base osc needs to run *really* slow. Also, I need my ramp to start at exactly -1 when circuit starts (circumvented by a global on/off button + reset workaround). The thing that causes me struggle are S&H counters (used for slower than base osc cycles) and how to properly reset them. Using  the % function almost works, but not reliably, and only for fixed cycles.

>On the bright side, here is a hack that addresses the line feed issue on Linux.

Thanks for that! :) - I believe this is relevant for mac users as well. My workaround has been running the csv through a text editor that allows me to save with either or both.

Regarding future implementations of this and that (VST/MIDI/ETC), all of that would of course be great- but I am more curious as to what and how I can hack stuff here and now- the work you've done with this over the years, and the support you provide is unheardofly awesome!!! I would be ungrateful to expect anything more.

Finally, here's a piece I did 15(?) years ago employing abox v.1.x for bass, synthstringy thing and improvisational hazards (IIRC the impro circuit was a series of RC's functioning as gates/extreme lowpass filters at random) It's a very dark thing (my edgy emo years) but still a beautiful representation of what abox was capable of even in it's early years:
https://drive.google.com/file/d/0B0o9hUIkXjD0eDdBTmdkNnJuZWc/edit?usp=sharing

[Keith Blackwell]

Impressive sound shaping!

Since you have a bit of perl under your belt, I think that could be a more promising avenue. Let perl read the midi file directly using existing modules, then your custom perl script could output exactly what you want to see on the abox side of things. You could even calculate delta times and output them as floating point values corresponding to an abox time value (the delay since prior event before this event takes place, or whatever). That could greatly simplify the abox circuit interpreting the data.

Start here:
https://metacpan.org/search?q=midi

--
Keith W. Blackwell

[Keith Blackwell]

After a bit of reading, I think you *might* get by with just reading a midi file as an "opus" structure (construct "from_file": https://metacpan.org/pod/MIDI::Opus ), and then writing it out to a file (write_to_file(), though you might also start out by trying the dump() method), but you write your own version (override) of the event "encode" method ( https://metacpan.org/pod/MIDI::Event ) to generate a string that you want to be output for that event (could be empty if irrelevant to abox). The event pod (previous link) describes what you can find in an event, so you know how to alter each datum to suit analog box needs.

If you get it working, please share. :-)

--
Keith

[Andy Turner]

Rune said:
"- but I am more curious as to what and how I can hack stuff here and now-"

That makes me happy. Every time I tackle VST (as I did earlier today)
I run into the same problems with UI details far removed from what I
started to do in the first place ... the next time I mention vee ess
tee somebody slug me :-)

But I'll continue to contemplate a script like way to make new ABox objects ...

Here's the hex editor hack for adjusting the linefeeds in the csv
writer. Applies only to ABox242 as retrieved from
<https://sites.google.com/site/analogbox2/download/abox242.zip>
In a hex editor, scroll down to file offset 030B00.
Verify that you see exactly the numbers shown below:
030B00 D4 6A 00 54 6A 02 52 FF B6 18 47 00 00 FF 15 58
Change the 02 to 01 and verify that you now see:
030B00 D4 6A 00 54 6A 01 52 FF B6 18 47 00 00 FF 15 58
Save the file.
Done (not bad for changing 1 byte :-).


Heh heh, you Perl guys make me jealous; all those dollar signs :-)


--A

[Rune Lund Sørensen]

[deleted my previous reply, as there was an error in the attached file]

Sooo - like I said, my perl is rusty (plenty of dollar signs in php though). I did however manage to modify the php midi class from here: http://valentin.dasdeck.com/php/midi/

It saves the midi stream from each track to a separate file, in abox readable (CF+LR linefeeds), comma separated, numerical (integers) format, excluding metadata and sysex messages (optional flags for translations of those are possible - though not yet abox readable - they are saved in separate files for now)

It works like a charm on my linux system with a php cli interface - would love to hear from windows users (see http://php.net/manual/en/install.windows.commandline.php if you don't know what you're doing).

I've yet to design an interpreter in abox - the problems I foresee are timing when more than one event occurs withing a short (or at the same!) time...

It would not be hard to add functions to the classes allowing for alternative interpretations (like say a monophonic stream of note on/off msgs). I kept it true to the midi stream for now.

There's an explanatory readme file included in the zip file.

Suggestions / ideas / critique is encouraged - also, if someone beats me to building an interpreter circuit in abox, I wont hold it against them ;)