(retroactively posted Nov 2015)

Comment...

(retroactively posted Nov 2015)

Comment...

First, from a recent 'git log' command:

commit f94d5a07541a672b4446248409568c20bca9487d
Author: Justin <justin@localhost>
Date:   Sun Sep 11 21:52:27 2005 +0000

    Vss2Git

diff --git a/jmde/mediaitem.h b/jmde/mediaitem.h*
new file mode 100644
index 0000000..52b8a8f
--- /dev/null
++ b/jmde/mediaitem.h
@@ -0,0 +1,37 @@
#ifndef _MEDIAITEM_H_
#define _MEDIAITEM_H_

#include "pcmsrc.h"
#include "../WDL/string.h"

class MediaItem 
{
public:
  double m_position;
  double m_length;

  double m_startoffs;
  double m_fade_in_len, m_fade_out_len;
  int m_fade_in_shape, m_fade_out_shape;

  double m_volume, m_pan;

  WDL_String m_name;

  PCM_source *m_src;
};

class AudioChannel
{
  WDL_PtrList<MediaItem> m_items;
  double m_volume, m_pan;
  bool m_mute, m_solo;
  WDL_String m_name;
  // recording source stuff, too
  // effect processor list

  // getsamples type interface
};


#endif

* Trivia: guess what jmde (JMDE) stands for?

..and to think, back when we used VSS we didn't even have commit messages! Soon after, "AudioChannel" became instantiable and went on to be known as "MediaTrack", and as one would hope many other things ended up changing.

Wow, 9 years have gone by.

I've been having a blast this week working on something that let me make this:

The interesting bit of this is not the contents of the video itself -- 3 hasty first-takes with drums, bass, and guitar, each with 2 cameras (a Canon 6D and a Contour Roam 2) -- but how it was put together.

I've spent much of the last week experimenting with improving the video features of REAPER, specifically adding support for fades and video processing. This is a ridiculously large can of worms to open, so I'm keeping it mostly contained in my office and studio.

Working on video features is reminding me of when I was first starting work on what would become REAPER: I was focused on doing things that I could use then and there for things I wanted to make. It is incredibly satisfying to work this way. So now, I'm doing it in a branch (thank you git), as it is useful for me, but so incredibly far from the usability standard that REAPER represents now (even if you argue that REAPER is poorly designed, it's still 100x better than what I've done this week). You can't go put half-baked, poor performing, completely-programmer-oriented video features into a 9 year old program.

The syntax has since been simplified a bit, but basically you have meta-video items which can combine other video items on the fly. So you can write new transitions or customize existing transitions while you work (which is something I love about JSFX).

I'm going to keep working on this, it might get there someday. Former Vegas fans, fear not, REAPER isn't going to become a video editor. I'm just going for a taste...

6 Comments

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

As a bit of an experiment, and after having set up a Twitter feed for Cockos, I'm probably going to start posting more random things (that I wouldn't bother updating this blog for) to twitter.com/lejustinfrankel... All that I have so far is a link to a mp3 I made today. Maybe I'll complain about [insert random API here] from time to time, too. The big meaty stuff will go here, still, though. For example, a discussion I've had with a friend:

Someone really needs to make an open system (think web, or email) for social (or anti-social) content publishing. Imagine a world where all of the content of each user on Facebook can be hosted and delivered by the provider of your choice (or yourself), and where the privacy controls and failures are not controlled by one monolithic company.. *cough* hurry up people *cough*.. The hard part, of course, would be getting such a thing to the size where it is useful, but there should be enough people out there interested. Speaking of which, this Onion video is absolutely brilliant:





Recordings:

staring makes things disappear

9 Comments

I have occasionally found myself in conversation, often in the presence of alcohol, about the ownership and value ideas. This post will attempt to document my current state of mind in these matters.

We routinely say "I have an idea", but I assert that nobody can own an idea. The closest one can come to owning an idea is to have private (possibly exclusive) possession of it. Sitting on an idea (or indeed implementing it and using it privately) could prevent others from implementing the idea, but it also would not prevent them. What is interesting about this, too, is that one would have no way of knowing if they had exclusive possession of the idea, since others could also possess it privately.

I've often heard things such as: "If I have an idea for something great, I should be able to benefit from it." I don't think it is that simple, nor do I think it should be. I like to imagine it from the perspective of conservation of energy. In my opinion, "having an idea" doesn't cost anything -- there's no work done, no trial and error, no refinement, no experimentation, it's purely the creation of an abstract concept. All of the work, all of the energy required to develop the idea into something real, that happens after having an idea. All of the work of implementing (or at least designing an implementation or possible implementation) is the where the value is created, and that is from what a person should be able to derive benefit.

If you suppose for a moment, that someone could have some sort of exclusive right over an idea, what would that actually mean? Could they prevent other people from doing anything that could be conceivably based on that idea? Could they demand a share of any derived revenue, or control? Could they demand credit? For how long? Ugh, chaos follows. The world would grind to a halt due to this complexity. The advantage you get for having an original (or at least somewhat original) idea is a slight head start.

An idea is something that one can benefit from, but that the rest of society also has the same opportunity for benefit. This actually makes me quite happy.

What does one do if they have an idea and want to make it into something real, but have no applicable skills? Hire people. No money? Make non-disclosure agreements or other contracts which will help protect what other people do with the information you given to them, and prevent them from doing other things that could possibly relate to the idea. This is a joke, though, few talented developers will agree to these sort of terms. Both sides need to have something of value to offer, and ideas are not value held by either side, because they are not able to be owned.

A friend brought the subject of Facebook up after seeing The Social Network.

1. Facebook became huge because of how it was made and marketed.
2. The idea for Facebook wasn't a new, nor original, idea.
3. Even if it was some brand new idea, it doesn't matter, since nobody can own the idea.

TL;DR: Ideas are worth a lot to society, but not much to individuals. Execution is the opposite.

Finally, some advice for anybody who wants to make things and profit from them: figure out something you can contribute; ideas aren't enough. If you're content to just contribute to society: publish your ideas, let people use them, and hope for the best.

(also, a related post that I previously linked to and agreed with, but the notion that the worth of ideas differs for society as a whole vs the "owner" is new for me)

7 Comments

4 Comments

I love these guys, I can't wait until next week for their show. Anyway some of their (old?) demos/unreleased tracks have shown up on youtube, and are really wonderful. Such low quality and such good result. Here's a little playlist of some of them I put together:


Also, I would highly recommend their album "Innerspeaker", as well as the EP that has the song "half full glass of wine" on it. Both of those are outstanding.

Recordings:

freeform jam with louie

4 Comments

I wonder what the total number of kW hours required to say, run the Apollo 11 mission. One factor would be in the fuel required, but I also mean in running the whole operation, manufacturering components, running control rooms, processing fuel, moving the rockets around, etc etc.

Which brings me to the fact that I just got a "Kill-A-Watt", after reading this blog post. I haven't tested everything yet (nor will I ever hah), but here are the results for the things I have:

• iPhone charger: 0.0W when no iPhone connected, 6W when charging (the classic "you should unplug wall warts when not in use" thing doesn't necessarily apply!)
• ReadyNAS NV (old sparc model, 3 WD and 1 Seagate 1TB disks): 50W
• Samsung 24" LCD: 45W, or 0W when in powersave mode
• Q6600 2.4ghz computer with single 7200rpm disk, GeForce 8600 GT, UAD-1 PCI-E card, idle: 115W, full load (with UAD-1 going): 185W.
• Sony VPC-Z12 laptop (dual core i7, SSD, 13" 1920x1080 screen, full brightness): 17W when idle in "speed" mode. 35W when idle and charging battery, 77W under full CPU load while charging battery.^*
• Updated: Brother laser printer/scanner/fax: 6W idle
• Updated: Thinkpad X60 (1.83ghz C2D): idle 23W, 28W with full brightness setting
• Updated: PS3: 1W off, 100W idle, 120W in RE5.
• Updated: LG 36" LCD: 0.5W off, 45W on
• Updated: 24" C2D iMac: 125W idle, screen at full brightness, 146W full load
• Updated: ZT lunchbox amp: 18W cranked but not playing anything, 23W when playing loud

The biggest thing that struck me is that my laptop, under normal use conditions, is using less power than desktop's monitor ALONE. Wow. I'll test more things soon, I get to reboot once again to remove the Kill-A-Watt from my desktop now.

*I should also mention that this laptop is really wonderful, despite lacking home/end/pgup/pgdown keys, which makes me sad. It weighs only 3LBs, and is fast (i7 dual core, 4 threads, goes up to 3.2ghz or so in singlecore mode automatically), and even has an optical drive built in.

1 Comment

Here's a sparse musical improv I made with a friend.

Comment...

I've recently started using Perl for text wrangling instead of PHP -- it started after much of my PHP included a lot of preg_replace and preg_match calls, which got me wondering...

There's a certain satisfaction I get from perl that I don't really get from other languages. There's something about the density that makes it quite readable, at least for the author. Here's a script I wrote to automatically add a new build configuration, based on an existing build configuration, with some modifications, to a given .dsp (VC6 project file):

#!/usr/bin/perl
$sp = "Win32 Release";
$np = "Win32 Nitpicker";
$spd="Release";
$npd="Nitpicker";
$spdir="/Release/";
$npdir="/Nitpicker/";
$libfile = "../../nitpicker/libcmt_nitpick.lib";
while (<>)
{
  chomp;
  s/\r$//;
  s/\n$//;
   

  print $_ . "\r\n";
  if (/^!ELSEIF .*$sp".*$/ || /^!IF .*$sp".*$/)
  {
    s/^!IF/!ELSEIF/;
    s/$sp/$np/;
    @nc = ($_);
    while (<>)
    {
      chomp;
      s/\r$//;
      s/\n$//;
      if (/^!/)
      {
        my $tmp=$_;
        foreach (@nc)
        {
	  s/$spd/$npd/g;
	  s/$spdir/$npdir/g;
	  if (/^# ADD BASE CPP/)
	  {
	    s/\/Z\S *//;
	    s/\/YX *//;
	    s/\/FR *//;
	    s/\/FD *//;
	    s/$/ \/FR \/FD \/Zi/;
	  }
          if (/^# ADD CPP/)
	  {
	    s/\/Z\S *//;
	    s/\/M\S *//;
	    s/\/O\S *//;
	    s/\/FR *//;
	    s/\/FD *//;
	    s/$/ \/FR \/FD \/Zi \/MT \/Ot \/Og \/D "DEBUG_TIGHT_ALLOC"/;
	  }
	  if (/^# ADD LINK32/)
	  {
	    s/^# ADD LINK32 /# ADD LINK32 $libfile /;
	    s/\/debug *//;
	    s/\/out:/\/nodefaultlib:"LIBCMT" \/out:/;
	    s/$/ \/debug/;
	  }
	  if (/^# ADD BASE LINK32/)
	  {
	    s/\/debug *//;
	    s/\/map *//;
	    s/\/dll /\/dll \/debug /;
	    s/$/ \/fixed:no/;
	  }
          print $_ . "\r\n";
        }
        print $tmp;
        last;
      }
      print $_ . "\r\n";
      push(@nc,$_);
    }
  }
  if (/^!MESSAGE.*$sp".*$/ || /^# Name ".*$sp" *$/)
  {
    s/$sp/$np/;
    print $_ . "\r\n";
  }
}

In case anybody is interested, Nitpicker is something we've been working on that is similar to Electric Fence or other memory debuggers, but better suited for our workflow/design/etc. We'll probably GPL it once it matures.

6 Comments

I am posting this in case anybody debugging something needs to find it -- I did find mention of it on some Java related site, but nothing conclusive. This may affect VC2010, too, but I haven't tested it.

While VC 2005/2008 targeting x64 generates SSE code for floating point code, fmod() still uses the x87 FPU, and more importantly it assumes that the divide by 0 exception flag is clear going in (meaning if it is set prior to the call, the call will throw an exception or return #.IND regardless of the input). Apparently they assume that since the compiler won't possibly generate code that would cause the divide by 0 floating point exception flag to be set, then it would safe to assume that flag will always be clear. Or it could be a typo. If you use assembly code, or load a module compiled with another compiler that generates x87 code, this can be a huge problem.

Take this example (hi.cpp):

#include <stdio.h>
#include <math.h>

extern "C" void asmfunc();

int main() {
  asmfunc();
  printf("%f\n",fmod(1.0,2.0));
  return 0;
}

and hihi.asm (compile with nasm -f win64):

SECTION .text

global asmfunc
asmfunc:
  fld1
  fldz
  fdivp
  fstp st0
  ret

Compiling this (cl.exe hi.cpp hihi.obj) and running it does not print 1.0, as it should.

The solution we use is to call 'fclex' after any code that might use the FPU. Or not use fmod(). Or call fclex before fmod() every time. I should note that if you use ICC with VC200x, it doesn't have this problem (it presumably has a faster, correct fmod() implementation).

6 Comments

We've just released a new piece of open source software for Windows, called LICEcap! It allows one to create animated screen captures. I know, there's a lot of software out there that does this already, but none of them are both free and meet my needs, so we made LICEcap.

LICEcap has a nice UI (in that you position/size the window where you want to capture, and can move it around while recording). We support writing to .GIF directly (big thanks/credit/blame to Schwa for getting the palette generation working as well as it does), as well as to a new format called .LCF.

LCF compresses by taking a series of frames, say, 20 frames, and then dividing each frame into slices, approx 128x16px each. Each slice is then compared to the same slice on the previous frame, and (if different) encoded directly after the previous frame. zlib is used to remove redundancy (often slices don't completely change from frame to frame, i.e. scrolls or small updates will compress very well). This is all done in 16bpp, and the end result is quite good compression, and lossless (well, 16bpp lossless) quality. REAPER supports playing back the .LCF files, too. The biggest down side is high memory use during compression/decompression (20 frames of 640x480x16bpp is about 12MB, and for smooth CPU distribution you end up using twice that).

I should mention that the primary reason for us making this tool was the desire to post animated gifs of new features in REAPER with the changelog. Hopefully we'll follow through on that.

On a related note, tomorrow (or soonish), I plan to post my latest additions on how to make OS X applications not perform terribly (new one: avoid avoid AVOID CGBitmapContextCreateImage() like the plague. HOLY CRAP it is bad to use). Apple: please, for the love of God, either make your documentation a Wiki, or hire someone who actually writes (multi-platform) applications with your APIs to write documentation.

9 Comments

(after spending much of the day banging my head against the wall)

#include <stdio.h>
struct test1 {  double b; };
struct test2 { int a; test1 b; };
test2 foo;
int main() 
{
  printf("%d\n",(int)&foo.b.b - (int)&foo);
  return 0;
}

What does this print? On Windows, it prints 8. On OS X (or linux), it prints 4. Which means, if you access foo.b.b a lot, it will be slow. UGH. I guess that's why there's -malign-double for gcc. Now if I can just figure out how to enable that for Xcode...

Recordings:

freeform jam with brennewtnoj

7 Comments

Another Wiener/Stack enterprise:

The Vacation [4:27] (I've named this without consulting the others)

The last verse is particularly good, IMO, starting about 3:22 in.

Read Dracula last week. Wasn't a huge fan of vampires before reading (Zombies FTW), but really enjoyed it, perhaps since everybody in the book were not terrible vampire fans either..

1 Comment

I ordered a Digilent Nexys2, and have been reading up on HDLs (primarily Verilog since it seems closer to C than VHDL).. Mmmm. Should be fun.

Have a few ideas for things to try, but I won't post them here just yet.

P.S. a song.

1 Comment

So in 1996 and 1997 I wrote a 3D library called Plush. Here is a screenshot from then:

It was written in C, it tried to be very portable (reading through it now, I'd say almost to a fault -- kinda annoying ;). There were some nifty things about it:

• 256 color output with adaptive palette creation and management
• multiple light sources
• piecewise linear perspective corrected texture mapping
• Gouraud shading with color ramps that let you do fakePhong
• optional Z-buffering
• environment mapping
• object hierarchies
• frustum clipping
• cameras
• splines
• matrix functions
• primitive generation
• very basic translucency

Totally useless today. But it would run SO fast with 20x the power available...

The code itself wasn't too bad, some stuff that I had spent ages tweaking and getting to run smoothly would surely be reusable.

So in about 8 hours of work I transformed it into Plush2, which is similar to the above, except simplified in C++, renders to 32 bit per pixel output, integrates with our LICE compositing engine, and supports the following new features:

• 24 bit color output
• multiple COLORED light sources
• Texture mapping (piecewise linear perspective corrected) with optional BILINEAR filtering and support for any sized texture, support for texture transparency.
• Colored Gouraud shading
• Z-buffering
• True surface transparency support
• Multitexture support (one or both textures can be used as environment maps)
• Full control over how pixels are combined at render -- add, mulitply are supported replace, all with alpha control.
• No limits on number of light sources, triangles, etc.

A screenshot:

Yes yes I know 3D stuff has all been done a ton, just thought it was interesting bringing things back from the dead to see what would be reusable. Now I'm going to go hug my 2.4ghz multicore processor.

This will be a part of the next WDL release, in case anybody cares, ha ha. It does compile down to pretty small (though not small enough to go making a 4k demo with it)

9 Comments

So while playing with some code to model a resonating spring (F=-k*pos), I discovered that the model I was using produced a very good sine wave approximation. This isn't normally something terribly interesting, as you can approximate sine/cosines very easily, but it was actually quite low complexity -- an iterative approximation with only 2 multiplies and 3 adds per sample. It can also generate the cos() (well, a 90 degree shifted signal) for each point for just one additional multiply.

The error is pretty low for the first few cycles, though after a bit it does drift in relation to the correct wave. I'm not going to spend too much more time on this, but if anybody wants to see if there's some way to correct it, go for it (it may just be rounding error, though, of course).

Here is the code:

// setup:
double cos_sc = PI/period_samples; // PI/n for a period of n
double pos=0; // actually sin(initial_state), 1 for cos(), 0 for sin()
double vel=1/cos_sc; // actually cos(initial_state)/cos_sc, 0 for cos(),1/cos_sc for sin()
double tmp = cos_sc*cos_sc;
double tmp2 = 1.0/(1.0+tmp);
double mul1 = (1.0-tmp)*tmp2;
double mul2 = tmp*2.0*tmp2;

// per-sample calculation
double output_value=pos;
// double cosine_output = vel*cos_sc;


// iterate to next sample
double newpos = pos*mul1 + vel*mul2;
vel -= (pos+newpos);
pos = newpos;

Ta-da! If anybody wants to go and do some fancy pants math to show why this works, too, I'd love to hear it... :)

3 Comments

Found my laptop with ergonomic keyboard!

Recordings:

freeform jam with newtchr

1 Comment

Can you please configure your mail servers to check the reverse-DNS on incoming mail? For example, if an email comes from "soandso@somedomain.com", please, for the love of God, check the MX record for "somedomain.com" and make sure it matches the server trying to deliver you mail?

For some reason people like to spam faking some of our addresses, so we get a bazillion "delivery error" messages. UGH.

11 Comments

Oh my god this one is so good:

Scrubs Theme Remix of Ode to ZB.

Laughing my ass off here.. awesome

1 Comment

Apparently someone remixed the vocals to the song "Ode To ZB" (which was an improv with me and Dave Biderman), and it appears it was played on some faraway radio station:

Kivonat Radio

The original track is here:

Ode to ZB

Woohoo!! So awesome!

2 Comments

Radiohead's Remix Thing looks neat a glance. But I think they missed the boat here and should've done it differently.

1) Don't make us use iTunes, for the love of God (sorry, Steve, but you know I'm right). 7digital or whoever else would've been forgivable.

2) Making people PAY for stems is dodgy. It would be one thing if we could buy stems for our own enjoyment of the whole album.. THAT would be worth buying... I understand they probably want to not be paying for the bandwidth--but seriously, use BitTorrent then or something. Nevermind that, if they didn't want to pay for bandwidth, why would they have all the remixes on their site? None of them seem to play for me, so maybe they didn't get enough...

3) The terms of the remix site are pretty terrible. I mean, giving them total ownership of everything that you upload just sucks. It's completely one-sided. Not only do I have to PAY them for stems, but anything I give back to them they get ALL rights to, and I get absolutely NONE? This is a tough sell.

Anyway, it's just disappointing. With just some slight changes this could feel like so much less of an marketing stunt and more like something legit and good.

2 Comments

Was reading an article on Bruce Schneier's blog about software lock-in, and found this quote intruiging:

Economists Carl Shapiro and Hal Varian even proved that the value of a software company is the total lock-in. Here's the logic: Assume, for example, that you have 100 people in a company using MS Office at a cost of $500 each. If it cost the company less than $50,000 to switch to Open Office, they would. If it cost the company more than $50,000, Microsoft would increase its prices.

I absolutely despise artificial or intentional lock-in and am attempting to make a software company that tries (actively) to do as little as possible to lock people in-- nothing, that is, except making the best software possible. Yikes, there is a long shallow road ahead of us...

6 Comments

JUST KIDDING. Quite the opposite in fact. It's been really exhausting porting stuff to OS X. Here are some reasons why:

1) Poor (and often hard to find) documentation-- Yes, some of the newer APIs are decently documented, but dig in and try to use ATSU to render text, and it's a world of pain. Looking through header files that all seem to assume you know what to do. This is tolerable, though, with enough digging you can find what you want.

2) The AudioUnits SDK-- the API for AudioUnits is defined in a header, but not documented. So to use AU, you'd have to either just use the SDK (with EXTENSIVE amounts of code), or reverse engineer it to figure out what calls you need to do to control the plug-ins yourself. Someone obviously spent a lot of time defining an extensible plug-in API, why the fuck don't they document it?! I mean, really, just a "first, call this, then, call that, then, when you're ready to process X, do Y." If this info is somewhere, someone please let me know... (see the next point)

3) The previous two points might to be related to the fact that Apple seems to assume that as a Mac developer, I've been developing for macs continuously since 1984, and have religiously read the developer mailing list since whenever it was created. Apple: for the love of god find some way of getting those mailing list posts linked to/from the relevant documentation pages.

4) There are WAY too many ways to accomplish similar things. The classic example which I bitch about a lot is text rendering--last I checked, there is CoreText (apparently awesome, but 10.5 only), CoreGraphics text functions (seem nice, but lots of limitations including non-functioning text measuring), HITheme rendering (which is nice but doesnt give you much for font style selection), AppKit NSString/NSAttributedString drawing (great, but slow), ATSUI (seems to be the best all around but takes a bit to get to the point where you get what's going on). I understand that there are historical reasons for these APIs, but again, this can be fixed with proper documentation (perhaps a page describing all of the APIs and their benefits and drawbacks).

5) Addition of new APIs in new OS versions. I know Apple wants to sell new OS versions, but from a developers standpoint, it's really difficult to properly support multiple versions of OS X. I'd like to use new OS features if available, but fall back to old versions if not. If there's a clean way to do this, I'd love to hear about it -- on Windows we usually just load the appropriate DLLs if available..

6) Performance on OS X for basic graphics drawing seems terrible. Perhaps if you take advantage of the highly OS X specific stuff, you can get around some of this, but as an example I made two native projects, one for OS X and one for Win32, that create a 640x480 window and try to draw at about 30fps. They fill the background black and draw white lines. On Windows basic double buffering is used, on OS X the system buffers the drawing. The OS X version uses Cocoa and CoreGraphics to draw, and the view is opaque.

The source code which you can build is here (VC6/win and Xcode2.4+ for OS X required).

Results: on the same Core2 hardware: OS X: 11% CPU use. WinXP: 1% CPU use. In fairness to OS X, it was drawing pretty antialiased lines, however when I disabled AA on the OS X build, the CPU use went _UP_ to 20%. Go figure. It's not really the line drawing, either--make it draw just one line the numbers dont change much...

Well I don't have anything to really bitch about Windows right now, but I'm really disappointed with all of the VC++ builds after VC6. The issues are a plenty, but it makes it hard to upgrade. All dynamic linking uses msvcrt71.dll etc which even MS doesnt distribute anymore, so you end up having to static link. Bleh.

I guess most people don't care about the size of their software, but for us keeping the program size down is also part of keeping the development process fast and efficient. If I have to upload a 30mb installer and everybody has to download one to test...

14 Comments

We played a fun show last night, should have some video up soon.

Man this is funny shit though (which I first read on At Ease), Lily Allen complaining about Radiohead, "It's arrogant for them to give their music away for free - they've got millions of pounds. It sends a weird message to younger bands who haven't done as well.".

YEAH! THATS MESSED UP! And all those people making open source software shouldn't do that either, because it's unfair to all of the soon-to-be Microsoft's of the world as well!

(As a side note, sorry Craig, I know you like Lily Allen, but think how this could be directed at Prince, too)..

The comments on that At Ease article page are hilarious, though. Some great reading, especially if you are putting of write a tab control wrapper layer...

2 Comments

Denny insists that I update this, since he checks it often, and I guess since I'm the only person on the planet (other than my wife, at least) not to be on Facebook, it means he has to check it himself, or something. Speaking of which, LEAVE ME ALONE, FACEBOOK! Getting AIM messages from you is ANNOYING AS HELL.

We've started on REAPER v2. It won't be long before 2.0 beta is ready. A ton of good things in there. Really good. Stuff that before, I might have said "this might be kinda nice to have" then after I'm feeling like I can't imagine how I would have gotten by without it. The list of stuff done since the last public release is about 20 lines long so far.

I don't really like doing non-public builds of software. On one hand I get to hold out and surprise users, which is nice to do once in a while. But on the other I feel like I'm running with a MUCH smaller testing pool and as a result I have to be very careful--which is tough though because some of the things we're doing are big and awesome. Oh well, we'll sort it out with a "2.0 beta" or something soon enough.

It's been a month since the last post.. funny how this timing is. What else has happened? Had a vacation.. Dave Wiener and I made this song. I got a 1TB SATA drive (awesome!) to back up the "recordings" folder of my formerly large 1.2TB array to. Dammit why did I end a sentence with to? Dammit I did it again!

Recordings:

freeform jam with newtonbryan

3 Comments

Been updating NINJAM, after integrating it into REAPER. The REAPER version has a much revised UI, and now supports sending stereo streams, a low latency voice chat mode, and will soon get a fancy "Session mode" that will ease long distance collaboration on projects.

Also updated the NINJAM AutoSong program and web site.. Been listening to playlists of random songs cut, and they're getting very good! I improved the program that does the cutting/mixing last week too.. Uses smarter volume detection and mixing logic, also does nice fadeouts.

Been having fun improving various aspects of REAPER that have been lacking.. The biggest one coming that's almost done is making loop selections and playback and recording sub-sample accurate. In previous versions looping was only accurate to the audio block. Soon it will be VERY accurate..

2 Comments

I'm doing a little guest hosting spot at GearSlutz for the next couple weeks..

Comment...

I knew *SOMETHING* good would come out of DRM...

Thanks to Apple and EMI doing DRM-less tracks, we got a kind mention from Eliot Van Buskirk being interviewed on an NPR show (it's arond 18 minutes in). The mention referenced NINJAM, as well as played a clip of a song I made with my friend David Wiener, A Little Pop Will Save Us All.

OK OK I know it's just NPR, and it's just a 10 second clip, and some of the details are wrong.. but hey, IT'S FUCKING NPR. OR WAIT, IT'S FUCKING PRI.

as in prime.

3 Comments

In August I began cleaning up REAPER's source code, and began separating the platform-specific code (mostly UI) from the mostly-portable code. Ten days ago, after 3 months of doing that while also adding new features and releasing new Windows versions every few days, I began spending a great deal of time actually writing a bunch of Cocoa code so that we could have it run on OS X.

It has gone very well, expect some preview version around Christmas.

I love it when this stuff goes faster than I had expected. I'm going to detail some of my experiences here.

There's a lot to like about programming on OS X, but there's also plenty of idiocy.

CAUTION-Boring programming discussion follows. These are mostly things that I have sort of, but not completely correctly, working.

For example, if you wish to draw text, there are countless ways to do it, and at least for what I wanted to do (emulate DrawText for our GDI emulation layer), I still haven't found a way that works as I want. The first way I tried was using CGContextShowText, which worked, except the only way I could find to measure the text before, or after drawing it didn't seem to work (using CGContextSetTextDrawingMode with kCGTextClip to modify the clip path, then get the bounding rectangle of that). So without any way to measure the rendered text, I had to find another way. I could use NSAttributedString to draw, but the first problem is that I wanted to supprot drawing to an arbitrary CGContext, which may or may not be the "active" context. Then, suggested to me, was to use Carbon's HIThemeDrawTextBox etc, which isn't really documented at all (other than in the header file and some examples). HIThemeDrawTextBox works, except the font I selected using CGContextSelectFont isn't used. It appears I could use some other API to set the font, but I havent spent that much time on that. Why can't there just a be a simple, working way?! At least win32's DrawText just works (though I hear the internals are a nightmare).

OK I won't go too much more into those sort of things. The good things are some things are just easier. Anytime you want to modify the behavior of something, it's WAY easier, since you can do a simple objective C subclass, rather than having to do the tricky hacks we do in Windows. Porting the customizable keyboard code to OS X took an hour or so. Getting it to work originally on Windows took many times that.

Rendering with Quartz just looks nice, too. The plain Windows GDI calls just look harsh and cruddy in comparison.

Here's an interesting challenge: on Windows, REAPER renders its play cursor (the line that moves constantly with playback) by using XOR drawing. It renders it by flipping all of the bits in the line, then when it needs to erase the cursor (in order to draw it in the new position), it can just XOR again. Win32 makes this available by using DrawFocusRect(). Anyway, on OS X this isn't possible, to my knowledge, because the system handles so much of the drawing process. I didn't want to be responsible for updating any of our track view at 30fps+, so I had to come up with another solution. After some experimentation, I found that you could create a new NSWindow, make it a child of the main window, and move it around as the play cursor. And it works, the system handles redrawing the track view, from its cached rendered version, so it's FAST, probably hardware accelerated, and you can do neat things with the alpha channel of the cursor. The verdict: while you can't do oldschool things like XOR drawing, you can do things sexier.

So to aid porting, I've created a new part of WDL (our general reusable code library, pronounced "whittle"), called SWELL (Small Windows Emulation Layer Library or something). So far it emulates (at an API level), portions of the Windows GDI, menu API, MessageBox, ini file (GetPrivateProfileString etc), and a bit more. Eventually we'll probably BSD license SWELL, too.

One interesting thing in SWELL is a set of macros and small functions that let us paste in menu definitions from a .rc into a C++ source file and have it generate a HMENU for it. Fun use of the C preprocessor, if you ask me.

Anyway, this is all challenging, and as a result, mostly fun.

I previously said I was planning on writing an article on coding style etc, and while I haven't gotten around to finishing it, I'll go ahead and discuss some of it.

1) If you program, and you're working on something that you expect to be working on for more than a couple hours, use version control. The benefits are countless. Safety, yes, but also, it gives you the ability to easily see everything you've done (if you're religious about checking your code in often), and even more importantly (to me), it lets you diff and review your changes before checking in. I do this all of the time, to make sure everything I did was everything I wanted, and that I didnt fuck anything up.

2) Don't be afraid to let things get messy. A very common (and valid) sentiment in programming is to avoid "premature optimization", where the programmer spends too much time too early on some part which may or may not even need it, introducing complexity for the sake of possible speed improvements etc. I don't hear people say this much, but I think you should take the same stance on organization. If you're programming software, and you need to add some new function for some task, don't be afraid to just toss it in near where you need it, and see what happens. Don't go creating tons of new files every time you need them. Moving code around for organization later is easy, and if you don't do it too soon, you'll a) stay focused, and b) save time in the event that the code you added wasn't used. Which brings us to the next point:

3) Don't be afraid to toss out code that you've written. Sometimes you have some problem and code a solution for it, and at the end of it, you just don't like it. If you don't like it, and think you could do it better the second time, do it the second time.

4) Going back to point #2, don't obsess from the beginning about reusability. Write code that you need, and once you're using it and see how you actually need to reuse it, then go make it reusable.

5) Finally, evolve your code. Getting something to the point of limping is the hardest part, so you should try to get to it as fast as possible. Once you're there, progress is much faster. It's like waiting for a minute to pass. If you look at a clock with a seconds hand, it goes quick, but if you just stare into space, it takes forever. Get to the point where you can see progress, then enjoy it (and test your work often).

More later, perhaps...

I added a super simple thing to prevent spam on these comments, and it has worked perfectly. We'll see how long that lasts...

12 Comments

...that the rain stopped.

I think I need a few more days of not coding. Must... regenerate.. brain...

11 Comments

...where to begin. Tom got married last weekend. Was one hell of a fun weekend. I was a bit worried it would be too uncomfortable, out among the orange trees, but the weather turned out great, Brennan and Isabelle brought an RV, and we all had a good time (and punched oranges).

Got to fly the little RC heli out there too, which was fun.. so when I got back I finally installed the upgraded symmetrical rotors, new motor and heatsinks, and LiPO battery and voltage alarm. Flew it inside today, though didnt do anything fancy since I'm not that good yet.

I heard back from Mackie, with a response that stupified and angered me. They only license documentation for the MCU under NDA to select companies (as in, not us). They don't seem to care about their customers, just their own (less than obvious to me) interests. I can only hope I don't get the same nonsense from Propellerheads, because I think people using REAPER will want Rewire more than full MCU support anyway (REAPER already supports the MCU somewhat, but without doing a lot more research it can't do all the fancy things that the MCU is capable of). Sigh. The pain of trying to enter a market that is very established and saturated. But I'm only mildly deterred. If Propellerheads *does* dick me around, I will do one of two things-- either go to Stockholm and try to convince them with beer (though don't get any ideas, guys), or just do what I've been meaning to for a while, and port JACK to Windows.

Speaking of Windows, after BootCamp was released, Steve convinced me to get (at a discount at least) a MacBook Pro. So I did. For running OS X it's pretty good, but as a Windows XP laptop it really kinda sucks. There's a few driver issues that need fixing (no backlit keyboard in windows, sound always goes out speakers, using the built in camera causes BSoD, etc), but the big hardware issue is that the Mac keyboard is lacking keys. Specifically: insert and backspace(delete). I did find some good 3rd party utility that does help a lot allows all sorts of remapping, and enabled the mac's FN key. And finally, the thing gets HOT. I guess that's to be expected with 2x 2ghz cores, but still. I got spoiled by my little Sony's 1ghz P-M that runs nice and cool (and granted, slow).

Oh yes, and southpark this week was SO awesome.

Recordings:

notthefirsttimealone

9 Comments

So I'm sitting in the dining room of a friend's house, on my laptop, listening to random music-like things. I think soon I'm going to make something like Debris for audio, specifically for NINJAM recordings, since they are in nice little chunks with some somewhat relevant metadata. Could be interesting, depending on how much intelligence I can build into it.

A little burnt out on the portable console hacking-- primarily because of things that are really hard to debug (for one, it seems that if I do an uncached write (the second to top bit of the address set) to memory, then soon after do an uncached read, it doesn't get the updated value. Which complicates things... The whole process of building, copying, running, repeat is a pain too. Anyway.

Get to move my work space soon, going to get a bunch of bandwidth at the new location, too. Yum.

And after this weekend, we'll have to get practicing for our show.

Speaking of music, got a fretless mexican fender jazz bass. So tasty. It has lines on it, thankfully, so it's not too hard to play, just gotta pay more attention. Here's a little mp3 of me testing it out on NINJAM.

3 Comments

Part II - Making Open Source Work

From my experiences, there really seems to be a right way and a wrong way to begin an open source project.

The Right Way

+ If you haven't already, write a usable working proof of concept of your software.

+ Do NOT create a sourceforge.net project for your software (see below).

+ Make a simple web page for your software. Provide downloads for the source and (if it runs on Windows or Mac) binaries. Perhaps even bundle the source with binaries, if it's not too big.

+ Put an email address on the web page with a link that says "send updates/patches/requests/etc to ". It often is also useful to put a list of things that you are intending to add, i.e. a "todo" list.

+ Continue to update and USE your software.

The big push here is that a sourceforge.net project should only be created for a project once it has enough people working on it to warrant it (i.e. more than a few).

From my experiences it is much easier for developers to get involved with a project if they can download a source tarball or ZIP file, make their changes, and send them back to the project owner, who can then merge changes appropriately. While the project owner should definitely be using some sort of version control, setting up a CVS server for other contributors isn't really that important, at least until other people start doing a very big percentage of the work, and having it as the recommended mechanism for access initially is a really bad idea, because the barrier of entry is higher.

The other things I suggest are:

+ If you use other SDKs/libraries, include a text file with the names, versions, and (preferably) download links for those SDKs/libraries.

+ Try to use only the most common libraries, to make it as easy as possible for other people to run and build your code.

The ideal scenario is, you create the initial version of software and thus begins the cycle:

+ Someone finds out about your software

+ That person wants a particular feature or functionality, so they add it

+ They send you a patch, you merge it into the main release

+ Repeat.

That's really all there is to it. Later on, if you have many people actively working on your project, you might want to consider public CVS etc, but even that isn't really that helpful, as you'll only want people whose code you trust to have commit access.. anyway, hope this helps people! I know it might obvious, but hey, that's why I named this post what I did.

1 Comment

Test flew my RC plane with camera mounted in it today, was fine. Balance good, weight not too bad, added power draw seemed OK, etc. Didn't have the receiver for the camera, though, so I don't have any video footage of it.

The main thing left to fix is that when the motor is on, the power gets so noisy that the camera starts fucking up. So after researching online, I've decided to go to Radio Shack in the morning and buy the appropriate resistors and capacitors (well, just one of each really), and build a lowpass filter. Judging by how the video looks when the noise is there, it appears to be correlated to the speed of the motor (the motor probably spins at upwards of 2000 RPM), so it seems relatively easy to build, say, a 30Hz lowpass (which using a 2.2 ohm resistor and 2200microfarad cap will give me a (workable) voltage drop of 0.2 volts, at 80mA load), which will hopefully take care of it. I'll buy some variety of resistors and capacitors to tweak the filter once I see how it works, too. Fun fun, math meeting electronics, mmm. I'm not sure what the frequency response curve is for a lowpass like this, so I'm shooting really low. Anybody have any experience with doing this? :) I guess I'll find out if I'm completely wrong...

Comment...

Part I - Choosing a License

Disclaimer: I am not a lawyer, these are my thoughts as a software developer.

For me, there are three basic licenses I consider when I'm releasing a piece of software.

1. A Proprietary License

This often seems like a safe first step--keep the source code to yourself, let people use binaries, etc. I'm not aware of any "standard" closed-source licenses one can use (are there any?). So it seems a lot of people end up copying other peoples (expensively crufted) legal text, which may or may not be that good, and raises copyright questions for the license itself.

At any rate, releasing software with a proprietary license has benefits, especially since you can completely monopolize the software, giving you potentially more opportunities. You can always open source it later, too.

The drawbacks to keeping source private are obvious, though. You can't get people to work for you for free! (See Part II, below)

2. General Public License (GPL)

When I want to open source my software, and also want to ensure that any derived versions of my software remain open source, I'll usually choose to use the GPL.

Contrary to what many people seem to mistakenly believe, by releasing your software GPL licensed, you do not give up any ownership or other rights. While you grant other people limited permission to your code, you still have rights including the right to license your code under other (potentially lucrative) licenses as well.

Licensing the software under other licenses does get more complicated once other peoples contributions find their way into your codebase, though. If you intend to license your GPL software under other licenses, you will want to control who can contribute to the codebase (See Part II, coming soon), and work out agreements with them.

3. BSD-like license

Using a BSD-like license on code makes it available for everybody to use, with very little restriction on what they can do with it or how (usually the main stipulation is how credit is attributed). It's really not too far from making the code public domain.

The upshot of a BSD-like license is that you (and everybody else) can do just about anything you want with the software. When other people contribute code, they're giving you that permission as well.

The downside of a BSD-like license is that someone else can take your software, and go make it (via big modification, or slight modification and promotion) into something huge-- and all you will be entitled to is a small credit. Now, the reality is that this could happen if the software was GPL licensed as well, but at least then you'd get access to the modified source code.

Conclusions

Ultimately whatever license you choose someone can always go and (rewriting if necessary) make something big out of your software, so (I keep telling myself to) worry more about the upsides and less about the down.

Proprietary licenses are really good for software where you feel you (or your close associates) will be working on the software a LOT, and want to maintain complete monopolistic ownership and control. This is very attractive to many people (myself included) for a lot of projects. It is completely respectable in my opinion, as long as you feel it is justified.

If however, you feel like a project would benefit greatly from having other people contribute, and the project has potential to be bigger than you've made it already, using the GPL can be a good choice.

I find BSD-like licenses to be good for licensing of libraries (or any other software that you generally want to be used as widely as possible), since people can link (and optionally compile) them with their projects, and not worry about the terms. Take zlib, which is used everywhere, or jnetlib, which isn't used as much but I'll mention for selfish reasons.

Coming soon: Part II (or: how to get other people to work on your open source project)

4 Comments

So I finally got an Athlon64 X2, and whoa, I love it. I had to get a cheap
PCI-E video card, though, because the integrated video didn't like the dual
core chip AT ALL. Was sorta a pain in the ass, but it's all good now (though
I'm out another $60 for a crappy X300SE). Whenever I'm running lots of stuff
(including autosong which loooves to chomp CPU) and I see the combined CPU 
use go above 50%, it makes me giddy. And everything UI stays so reponsive.
The other big thing that I appreciate is when some buggy application with
a high priority thread chews 100% CPU, I can still kill it trivially. This
has already saved me a couple times today. On a sour note, it seems my little
ST20G5 is slightly noisier with the added load of the second core and the 
video card (which is passively cooled, though), but is still quite quiet.
I've just gotten very spoiled.


songwriting

August 12, 2005
I started writing some lyrics for some music I wrote a month or two ago
("sparseish") today. Once I have inspiration for a song, and the music
done, I find it pretty enjoyable to write the lyrics themselves. Now if only
I could sing. Oh well, I'll enlist other people to help. Or wait, tons of 
people, maybe even. Here are my two initial versions crappy and crappier.
Here are the lyrics as a text file. If you want to sing on them, go for it,
just send me a copy. :)

Just note that you should take liberties with the timing, melody, and the lyrics
themselves (I'm really interested in what other people will do).

3 Comments

...and a happy birthday to my sweetheart.

This blurb is surprisingly shallow and shortsighted given the time spent by various people 
talking to the author. Maybe it was his editor's fault. At any rate, I'll take credit for coining
the phrase "fake-time" and point out that it's a feature, not a criticism. And that NINJAM has more
than a slight delay, but a huge delay--presumably, the other software/service/vaporware mentioned
has a "slight delay". Nevermind the other huge differences-- NINJAM working with actual audio 
streams, free software (as in speech), etc. I know it's just a blurb, but hopefully people will
investigate to see the truth. 

The other thing that bugged me was the use of "critics". Personally I haven't heard anybody be
too critical of NINJAM (i.e. haven't gotten any negative feedback, just positive and suggestions). 
At least, nobody who's actually used it. Some people who haven't yet will say "oh that sounds 
like it would be terrible", but everybody who has used it seems to enjoy it tremendously.

It's really a hugely addictive and fun form of entertainment.

Anyway... off to drink and eat a lot this week. woohoo.

8 Comments

So I got a Shuttle ST20G5 (I think) and a 90nm AMD Athlon64 3800+, and let me say this thing
rocks. It runs at the same clock speed as my old P4 2.4ghz, and is way way faster, and
insanely quieter/cooler (I can hardly hear it). And once the Athlon64X2s come out, I will be
able to upgrade to dual core easily. Hot (but not TOO hot).

It's been a while since I've seen an Intel CPU that has impressed me this much. 

Had some pain getting XP to install since I didn't have a floppy drive and my HD is SATA.
Got to learn how to add it to an XP CD, which was, err, fun. And had some annoying times 
getting my printer/fax/scanner to work (the drivers included with XP were hanging the system).
After a good 8 hours of fudging I got it all where it needed to be. Now to go grab a couple
USB-Serial converters for doing AVR development (since my old box had two serial ports, and
this one has none).

Bleh, my back hurts. WTF. More to this story later.

9 Comments

I posted a link on the Jesusonic Forum to the Jesusonic DirectX plug-in, woot.

Also, our show next tuesday is on, and we will be going on at about 8:00pm.
Hooray.
Here is a playlist of our last rehearsal (which is a mixed bag but 
entertaining no less).

Recordings:

freeform jam with brenchr

1 Comment

There's a new version of Pathsync up.  Thanks Francis and Alan! This new one 
lets you do a lot of nice things, see the whatsnew on the page.

2 Comments

OK so I still need to build the footboard for the new Jesusonic (which I will
do this week), but I just upgraded the board in this one to a via C3 1.2ghz 
board. The CrusFX still has a 1.6ghz P-M board in it. The difference in power
(and price!) between the P-Ms and the C3 is huge. But The 1.2ghz C3 is finally
powerful enough where in normal (and even excessive experimentation) I'm not
finding it running out of power. Yes, if I try, I can get it to run out 
(whereas with the P-M that is difficult sometimes even). So I think the first
run of Jesusonics will probably be 1.2ghz C3 powered.

If anybody is interested in purchasing one of the first run of Jesusonic 
hardware, let me know. It will probably cost around $1k, and will likely be
hand made and of very limited production. I'd like to gauge interest before
building the initial run.

I've still been using the 1.6ghz P-M based CrusFX for our practices, it's 
really quite fantastic, we tried using a Line6 POD XT Live for half of one
of the practices and while it was good too, it was also lacking in certain 
features (which makes me feel like making the Jesusonic is somewhat justified,
if not completely useful).

We had a fantastic rehearsal today, too, the mp3 is up. I can't wait for the
show (but I'm glad we have a little more time to get things solidifed ;)

Recordings:

freeform jam with brenchr

6 Comments

So apparently we're going to play on May 3rd sometime after 8pm at Studio Z
here in San Francisco. Our practice yesterday produced this decent collection of
songs. It's merely 35 minutes, but played live would be stretched out closer
to 40 I'd imagine. And we have a cover we might do, too.

4 Comments

It works now! All that's really left is to build the detachable footboard!
Yay. Here is a picture of the internals (what a big mess of wires, I know!):

...and the front:

...and here is an MP3 I made quickly with it.

Recordings:

onetakecrap

4 Comments

After a day at the beach, getting the tops of my feet sunburned, I came home and
registered brainal.org (think Brainal Sex), and then found myself building a very
strange website on it. <3 PHP.

2 Comments

Here is a lovely playlist of tracks.

Also, made an RSS feed for our full jams, not sure if that'll be
useful for people.

2 Comments

I'm protesting the use of the word "blog" by calling this a home page, which
is what it really is anyway. Not too different than the ones we used to have
back in the 90s, only a little more chronologically biased.

Here is another kinda entertaining song from that last (April 2nd) jam.
And another, and another.
Oh and here's one from yesterday with just me and Brennan.

Recordings:

freeform jam with brenbidernewton

9 Comments

After working on many of the parts seperately, I finally got to put the box 
together, and suddenly everything worked! (I have't done the audio subsytem
yet, waiting on parts, so this is just the UI and whatnot). Woohoo! My 
knobs were all backwards, but a quick firmware update later, that was fixed. 
And the range on the expression pedal needs calibration, but that'll be an 
easy software fix. And I think I want to put a hinge on the lid for easy 
access...

Got my temporary crown, joy. Somehow I've managed to get up early every day
this week (the week after DST change, at that!), and it's really driving me
into the ground. mmm need coffee..

1 Comment

wait what does that mean anyway? but at any rate, I (like Steve) will be getting
some bling in my mouth. functional bling no doubt, but bling no less. or so I'm
told. sigh. what I don't get is that in this age, they can't make a tooth crown
in less than 4 weeks? shouldn't they be able to do it in a week, if not a few
days? so instead I'll have to endure a nice plastic crappy temporary crown for
over a month? lame. I want instant gratification.


perhaps the best decision I've made recently was to ditch the cheap electronic
drum kit (which was in my office from back when I was testing Jesusonic with 
it) in my office, and replace it with another desk, which is devoted to 
electronics construction. it has made it so easy for me to build another AVR
board for the knobs on the new prototype (above). There's something just really
gratifying about making things easier to do (or at least not any harder than
they have to be). Oh, and here is a terrible mp3 (not quite scratching, yet, but 
maybe someday).

(oh and oops, yesterday's posting didnt go live until today, doh)

1 Comment