Showing posts with label osx. Show all posts
Showing posts with label osx. Show all posts

Saturday, April 6, 2013

Foot-switch MIDI Controller

Recently I've been playing around more with MIDI control of audio programs like Ableton Live and POD Farm effects program on OS X. Creating my own foot-switch controller seemed like an easy weekend project.

Ingredients:

  1. A footswitch ( https://www.sparkfun.com/products/11192 )
  2. Someway to get input into my computer. Teensy 3.0 ( http://pjrc.com/store/teensy3.html )
  3. Unnecessary number of LEDs ( https://www.sparkfun.com/products/11492 and all the bits that go with that: breakout board, LED rotary encoder )


Instructions:

  • Foot-switch goes into the teensy: simple pull-up resistor
  • Wire all up the rotary encoder breakout board pins to the teensy
  • Write some arduino code to read from/write to the serial port
  • Write an OS X program to read from/write to the teensy board via the serial port
Source Excerpts:

On the teensy I attach an interrupt on the pin the footswitch is attached to:

void setup() {
  attachInterrupt(foot1Pin, footSwInterrupt,CHANGE );
}

static int foot1PinDown = 0;
void footSwInterrupt() {
  foot1PinDown = (digitalRead(foot1Pin) == LOW);
}

void loop() {
  static int last_state = 0;
  
  if( last_state != foot1PinDown ) {
      uint8_t buf[5];
      buf[0] = 0x01;  // COMMAND
      buf[1] = (foot1PinDown) ? 0x1 : 0x0;
      buf[2] = 0;
      buf[3] = 0;
      buf[4] = 0;
      Serial.write(buf, 5);
      
      last_state = foot1PinDown;
    }
}


I don't use the rotary encoder for anything but the "Encoder" library provided by pjrc works well with the sparkfun breakout board/rotary encoder.

The ring-o-LEDs is just two 8-bit shifts out:

void updateRing( uint16_t v ) {
  digitalWrite(ringLatch, LOW);  

  shiftOut(ringDat, ringClk, MSBFIRST, v>>8);
  shiftOut(ringDat, ringClk, MSBFIRST, v&0xFF);

  digitalWrite(ringLatch, HIGH);
}


The most interesting part for me was figuring out how OS X's midi library works. This turns out to be pretty simple after looking at maxbok's CoreMIDITemplate.

On app startup register as a MIDI source. I.e. other MIDI programs that "read" MIDI messages will show "Footswitch MIDI Source" as one of the control surfaces:

MIDIClientCreate((CFStringRef)@"Footswitch MIDI Client", NULL, NULL, &_client);
MIDISourceCreate(_client,(CFStringRef)@"Footswitch MIDI Source", &_endpointRef );
MIDIOutputPortCreate(_client, (CFStringRef)@"Footswitch Output Port", &_outputPort);

When you want to send a note message:
- (void)sendNote:(uint)note on:(BOOL)on {
    const UInt8 data[]  = { on ? 0x90 : 0x80, note, 127 };
    ByteCount size = sizeof(data);
    
    Byte packetBuffer[sizeof(MIDIPacketList)];
    MIDIPacketList *packetList = (MIDIPacketList *)packetBuffer;
    
    MIDIPacketListAdd(packetList,
                      sizeof(packetBuffer),
                      MIDIPacketListInit(packetList),
                      AudioGetCurrentHostTime(),
                      size,
                      data);

MIDIReceived( _endpointRef, packetList );
}


The rest of the code is pretty teensy specific for opening it's USB serial port and reading from it in an asynchronous mode:

- (void)startSerialReader {

struct termios settings;
__block int fsw1_state = 0;
int port = open("/dev/cu.usbmodem12341", O_RDWR);
if (port < 0) {
fprintf(stderr, "Unable to open %s\n", "/dev/cu.usbmodem12341");
return;
}
__weak typeof(self) weak_self = self;
// Configure the port
tcgetattr(port, &settings);
cfmakeraw(&settings);
tcsetattr(port, TCSANOW, &settings);
_serialHandle = [[NSFileHandle alloc] initWithFileDescriptor:port closeOnDealloc:TRUE];
__block NSMutableData *comm_buf = [[NSMutableData alloc] init];
_serialHandle.readabilityHandler = ^(NSFileHandle *fh) {
// DO INTERESTING THINGS WITH SERIAL DATA FROM TEENSY HERE!
};
}



Results:

Here is a short video of the rotary encoder's RGB LED's cycling through colors while I push the footswitch down.


The hardware overall works great. You kinda get what-you-expect from the $5 foot-switch from sparkfun. It works but it has no tactile feel and you need to push it down quite hard to ensure it's actually switched. I'd like to experiment with some sort of optical switch arrangement instead of this cheap mechanical one.


Friday, January 8, 2010

InfiniteRay: A View-based platform

Introducing a side-project I wrote over the holidays. InfiniteRay is a cross-platform graphics platform which uses Lua scripting to manipulate a hierarchy of views. The goal of this project is to make it easy to write complex graphical applications. It turned out to be a pretty cool way to do some rapid prototypes.

You can check out the source here (BSD Licensed).
There are no binaries yet available. However it does build under win32 using mingw and OS X using xcode assuming you have all the prerequisite libraries (see below). Note: The Lua bindings are automatically created by gen.py in the /gen directory.

It's also still alpha-quality so if you're looking for a more mature platform check out the Love 2D Game Engine. InfiniteRay differs from the Love engine in a number of different ways but primarily InfiniteRay is C-based and Love is C++ based.


(Short Video Demo)


(The loader screen)

Features:
- Lua scripting language
- Structured view system to easily create complex compositing heirarchies
- Asynchronous resource loading from files or zip archives
- Drawing support utilizing the cairo graphics library
(http://www.cairographics.org/)
- Font rendering using the freetype font engine
- Asynchronous TCP/IP network support

Library Dependencies:
- FreeType 2.3.11
- Cairo Graphics Library (libcairo,libpixman,libpng)
- zlib


(The asteroid example)

Friday, January 9, 2009

Sandboxing Applications in OS X

Last month I spent most of my time studying the OS X Mach-O file format and the dyld. After playing around with Sandboxie on windows I thought it'd be fun to see how it could potentially be implemented on Mac OS X. The following is basically a dump of what I learned as I ventured into the world of the dyld on Mac OS X.

First, I should define what sandboxing means in this context. Sandboxing an application involves wrapping applications within a lightweight container which restricts what an application is able to do and in some cases changes the behavior of system functions completely. The goal of this type of sandboxing is to prevent an application from arbitrarily writing into the filesystem. Reads come from the source filesystem but writes are redirected into the sandbox filesystem. In this way sandboxed applications cannot change system files.

Is there a need for sandboxing on OS X?
I'm not a security expert so I cannot comment on whether or not sandboxing in this form is effective, beneficial or necessary on OS X. From my average developer's standpoint there are benefits such as:

  • Security: Yes, there may not be (m)any malicious apps targeted towards OS X but this could change. Assuming the sandboxing application is lightweight enough to run transparently to the user, there would be little reason to not run inside a sandbox.

  • Testing: Run app that is to be tested inside a sandbox. After running the app the sandbox can be deleted when done. No extra cleanup required, system never really was effected by the app.

  • Auditing: Track what application adds/removes/modifies files. To be fair there are auditing abilities built into OS X already, see audit(2). Accessed files can also be seen within the Activity Monitor application under the Inspect, 'Open Files and Ports.'


Ways to Sandbox Applications on OS X

  • Kernel Extension: From just a glance at sandboxie it seems to use a kernel-mode driver to get most of it's work done. Not having ever done kernel development before, I took a different approach. It could be that a kernel extension would be the cleanest way to achieve app sandboxing however the kext may then become a target itself if it were poorly implemented.

  • Some Sort of Emulation: This approach would involve running the process under an emulation layer like Valgrind. Patches do exist to get valgrind running under OS X and would be worth investigating feasibility. One downside would be the extreme performance penalty.

  • Function Interposing via Dynamic Library Insertion: Probably the most viable user-level way to achieve sandboxing. Below I have described how it would work.

  • Function interposing via Executable Modification: The details would be pretty nasty but you could modify the symbol table within the mach-o executable to point to other functions in other libraries. The problem is that all the other loaded dynamic libraries would need to be modified as well and that's where it'd be really messy.

  • Other ways? Certainly I'm probably missing other (easier) methods for doing this. If so let me know!



Function Interposing via Dynamic Library Insertion
(Before continuing, note that OS X occasionally uses two-level namespaces, which means that linux method of overriding functions may not necessarily work. Interposing does provide a nice way to address this issue.)

This approach involves directing the dyld (the dynamic link editor) to load a specified library at the process launch time. This is simply done by setting the 'DYLD_INSERT_LIBRARIES' environment variable to the target library before execution of the an application. The inserted library to be loaded has a special '__interpose' segment in the __DATA section which is interpreted by the dyld. Amit Singh's fantastic book has a chapter on interposing. Essentially it is a table of new and old function pointer pairs. Whenever the dyld needs to locate a symbol it will first look at the interposing table. This means that any dynamically linked symbol may be overridden by the library you inserted. So now you can redirect open/read/write system calls from the dynamic library.

The caveat of this method being that you can only call the real functions from within the library. This means that everything you need to do has to happen within the library.

So now we can insert our own versions of functions to be used by arbitrary applications. The question now is what functions should be interposed?
Nearly all the system calls are located within libSystem on OS X but there are also multiple versions of most system calls. From the average developer's standpoint this is handled transparently. In this case, though, it causes issues if the library is to robustly handle any OS X executable. For example, there are actually three different 'open' function calls:
open
open$UNIX2003
open$NOCANCEL$UNIX2003

Since we're not necessarily sure which version the executable is going to use each of the three versions of the functions need to interposed. See the multiple symbol variants link below for further explanation.

Of the system calls we are generally interested in the ones that deal with file and directory manipulation directly:
open
close
read
write
fstat
link
unlink
mkdir
mknod
mmap
munmap
opendir
...etc...


The list ends up being very long and there are a huge number of special cases. Such as how mmap function is handled, or how the /dev/* special nodes are handled.

Current Development State
So that's where I'm at now. Early on, I was able to run Safari inside of another shadow directory simply by hijacking the open call and opening a shadow file (first copying the original to the shadow directory) and returning the file descriptor to the shadow file. This worked surprisingly well but I wanted to get more ambitious and run any application from a single shadow volume file. To do this I've chosen to use sqlfs with sqlite. The result should be an injectable library which runs in user-mode without need for special privileges which writes into one file which can easily be discarded. Well, that's the idea anyway, it's quite a bit of work to be done still and I'm not sure if there is any demand for such a product.



Miscellaneous and References:

dyld was re-written in C++ from a C/asm version for rosetta 10.4/10.5? However, interposing is not included in the open source release?

Guard Malloc(libgmalloc) uses only DYLD_INSERT_LIBRARIES envar to override malloc and it does so by using an interpose table.

Two Level Namespaces

Executing Mach-O Files

dyld Library Reference

Mach-O Reference

Multiple Symbol Variants

OS X Kernel Programming

Thursday, July 10, 2008

ScatterBrain released


And now for something completely different...

ScatterBrain v1.0


Back in January I set out to create my own clone of a piece of software I thought was cool (a recurring theme I have). I call it ScatterBrain and it's a clone of the todo-list editor TaskPaper. Yes, I can hear the groans now, another todo-list program, yay!
It hasn't been in testing mode and it hasn't been in development mode either, it's just been sitting gathering dust for the past 4 months -- which is a waste. So I'm releasing it for free and without any sort of guarantee that it won't randomly crash or do anything else crazy.

Download

ScatterBrain v1.0 - OS X Leopard Only


If you do use it I'd love to hear from you @: grant -at- gxjones.com (Just know I cannot support this software unless I start charging for it. And if that's the case I recommend you go with the real thing: TaskPaper)

The Format:


It handles the typical taskpaper plaintext format:

Project:
- task

it also adds a group line which is identified by a '+' character and a section line which is identified by a '#':

#Some Section
+ A group

Clicking on the circle to the left of a task will mark is as "@done" as well as adding a @date tag with the current date.

Geeky details


Finally, if you absolutely need to change the color-scheme you can do it via tags within your text (I know that's uber geeky and not user friendly). Adding this to your ScatterBrain file results in project headers being black:

@pv_color_white(project-header-background-color,0.0,1.0)
@pv_color_white(project-header-gradient1-color,0.7,0.38)
@pv_color_white(project-header-gradient2-color,0.0,0.2)
@pv_color_white(project-color,1.0,0.75)


For reference, this is the default presentation context used:

@pv_color_rgb(group-color,0.0,0.5,0.0,1.0)
@pv_color_rgb(note-color,0,0,0,1.0)
@pv_color_white(background-color,1.0,1.0)
@pv_color_white(project-background-color,0.90,1.0)
@pv_color_white(project-header-background-color,0.85,1.0)
@pv_color_white(project-header-gradient1-color,0.86,0.65)
@pv_color_white(project-header-gradient2-color,0.66,0.3)
@pv_color_white(section-background-color,0.90,1.0)
@pv_font(project-font,user,24)
@pv_font(group-font,user,16)
@pv_color_white(project-color,0.25,1.0)



Development Status


I'd go back to it if there is interest. There were two killer features I was working on when I stopped development.

Known issues:


- large files will be fully reparsed and be very slow (so stick to smaller files); this was something I really wanted to address but never got around to it
- sometimes the formatting isn't updated
- formatting the background lags sometimes
- probably some memory leaks in there for good measure
- zero documentation - might be an issue for some people

Friday, February 15, 2008

New Time Machine Icon in 10.5.2


Time Machine got its own status icon in the top menu bar in the new Leopard 10.5.2 update. Why is this icon always here? I would prefer it to only show up when it's doing a backup. At the very least get rid of the little analog clock in the middle of it, I sometimes try to read the time off it, or maybe set the time to when it last did a backup. I might be wrong but the time it shows is currently meaningless and confusing. At least I can disable the icon in the system preferences...
/steps-off-soapbox