Mac/Linux port discussion

[eric_admin]

Wooohoooo!

There's lots of hurly burly left before it's usable, but I've managed to get a first pass build of OpenStomp Workbench running on Linux under Mono. Hurrah!!!!!

It turns out that Mono was choking on the Application icon of all things (sheesh!). The attached screenshot is from a version in which lots of code was stubbed out trying to identify the source of the problem, but its the very first time I got Workbench to boot under Linux so I thought I'd share it.

I can't say for sure yet whether this path will ultimately be successful, but I the functionality I'm getting now is extremely promising. If I can get the serial port handler and the icon menus working then everything else should be manageable, and this path (i.e. using Mono) will give me a single C# code base which supports Windows/Mac/Linux. There appear to be some minor graphical differences in the Mono draw libraries vs. native Windows, but if all the functional hurdles pan out then those should be easy to tweak into submission.

Workbench on Linux.png (154.99 KiB) Viewed 2430 times

[JimFree]

You can port the codebase to C++ using a cross platform toolkit such as wxwidgets (http://www.wxwidgets.org) if you are interested. The application would compile to 32 and 64 bit Windows and Linux, as well as Mac (Intel and PowerPC) and Solaris.

[eric_admin]

The original implementation of OpenStomp Workbench used an odd technique to create a separate serial port thread (basically, it spawned off a second hidden form in a separate thread context, and that form contained a serial port object). The method used was unconventional, and while it worked fin in .NET under Windows, Mono choked on it.

I have re-architected the serial handler to use standard C#/.NET threading techniques and now Mono is happy. After that, it turns out that the serial port implementation in the OSX version of Mono is broken. Luckily, someout out there on the web has created a replacement OSX Mono serial driver (Shaneo, at http://shaneo.blogsite.org/ , who deserves much thanks), and with a little tweaking I was able to get it working. After that, there were a few Mono annoyances to clean up (like it's incorrect handling of ContextMenuStrips assigned to ListView controls) and finally I have a generally usable OSX implementation of Workbench up and running.

OpenStomp_OSX_Screenshot.png (312.99 KiB) Viewed 2352 times

I need to polish up the new serial implementation (which still has a few holes), and track down some lingering Mono inconsistencies (there are several, but I expect them to be manageable) but I strongly suspect that all the major obstacles have been conquered and that an OSX WorkBench release is coming soon.

I haven't tested the new Mono code under Linux yet, but from what I've read the Linux serial port implementation in Mono appears to be functional, so I anticipate the build to operate under Linux without much additional tweaking.

[eric_admin]

The OSX port is fully functional now. There are a couple intermittent com port bugs to track down and then it will be ready for release. I haven't tested under Linux yet, but the current build runs under both the Windows and OSX versions of Mono, so I expect it to run pretty well under Linux too. The new build is a single executable which will run under Windows, OSX (under Mono) and Linux (under Mono). That way everyone will be running the same code, and future updates will be easy to deploy to all platforms.

Now that I've worked with Mono for a while I'm astonished that anyone bothered to take on the Herculean effort involved in creating it (Kudos to Mono development team, and to Novell). I can't really say that porting to Mono was easy. There are still a lot of issues one has to code around in the current implementation (2.4) but the fact that it's possible at all is ridiculously cool, and I'm thrilled that I was able to arrive at a cross platform solution with a single code base.

[howard]

I Finally placed my order today(Off course I messed up the international payment, but still...)!

I'm really looking forward to digging in to the effect development, and I will mainly do this from OS X(with the occasional dip into Linux and windows), so you'll get plenty of feedback if something goes wrong(used to work in QA at Opera Software once upon a time).


Howard

[eric_admin]

I've been chasing a weird serial data corruption bug in the Mac OSX version of Workbench and tonight I finally figured out that the OSX serial port driver is changing 0x0D's in the data stream to 0x0A's (i.e. Carriage returns to line feeds). Arrrrrrghhhh!! Stupid computers.

Knowing what the problem is should be half the battle. Hopefully I'll be able to track down a fix now that I know what I'm looking for.

[eric_admin]

I contacted the guy who wrote the OSX com port driver I was having problems with and he told me how to remove the default CR/LF translation behavior. The data corruption problem is now solved. Whoohoo!

The OSX version of OpenStomp Workbench 2.00 has gone beta!!!

There are two OSX users out there who have been given the beta to kick the tires. It has a few stability issues that only show up when running under Mono, so I'm working to clean those up. I haven't tried it under Linux yet, but I'll get the OSX version released first and then tackle any Linux tweaking I need to do.

[howard]

It runs!
Somewhat sluggish when moving around on the "bench" but it works. I've edited a couple of pathes with it, though I had a crash during loading of the Booster module posted somewhere else on the forum.
Didn't do any harm, module came up as supposed to.
Piece of cake to install it, just fired up Workbench and the Coyote was found on the first run!
I'm not sure about the Ram utilization though. It shows 0% all the time...


Howard

[eric_admin]

The sluggish drawing behavior when dragging objects around in Wokbench has something to do with the OSX Mono 2.4 implementation. I haven't figured out yet whether graphics operations are just very slow in Mono or whether there is an optimization in .NET which causes it to not really draw all the intermediate "frames" when you drag an object across the screen. There may be something I can do to code my own optimization when running under Mono; I can probably throw the mouse move events into my own queue and then ignore all by the most recent one. I bet that would pep things up considerably.

The RAM utilization tells you how much of the Coyote-1's internal RAM is being used by a patch. Any Effect Module which implements a delay uses RAM. Patches like Tremolo and Distortion don't. If you load the Delay patch or Tunstuff you should see a non-zeroRAM utilization.

[eric_admin]

Actually I misspoke a little there. There are two banks of memory available to Effect Modules: SRAM and RAM. The SRAM is large (1.5 MB) and has higher access times than the RAM which is smaller (4 KB) but faster. Tunstuff and the Delay use the SRAM. The RAM bank is too small for most delay-type effects, but can be used as scratch pad memory for fast calculations or filters. I'm not sure I've written any published Effect Modules which make use of the RAM bank so far.

You won't see the RAM utilization increase unless you load a patch containing a module which uses it, and like I said I don't think any of the currently published Patches/Modules do.