Porting a win32 MIDI SysEx application to MacOSX - macos

What is the easiest way to port a win32 MIDI SysEx application (a configuration program), to MacOSX ?
The application itself is written in Qt, but I have no experience in OSX MIDI APIs. Are there good enough drop-in replacements for calls like:
midiInOpen
midiOutOpen
midiOutPrepareHeader
midiOutLongMsg
and a couple more? Is there a decent source of information for someone who has never programmed under MacOSX to develop MIDI SysEx applications? CoreAudio?

I found a great little (just one .cpp file + headers) midi library - crossplatform and all :)
It's also a great source to analyse and to learn from.. a little nugget in the whole undocumented field.
http://www.music.mcgill.ca/~gary/rtmidi/index.html

What is your development platform? If you're writing a Native Coca Application for the mac, Apple wrote a complete framework to deal with the Midi traffic named CoreMidi. The CoreMidi framework deliver the whole package of midi (include SysEx) and even extend it with network support.
I recommend having a look at Pete Goodliffe blog post of using CoreMidi for iOS devices. Although you're not developing for iOS, there is a lot of CoreMidi related information there.
There is a simple, yet brilliant, application that I use a lot on my studio named: Midi Monitor which is an open source application. I recommend having a look there too.

Related

Fastest/easiest way to build a WebKit based Windows application?

I am a web developer. I don't know how to build native Windows applications. I recently built a Mac desktop application (using MacRuby) which is a WebKit wrapper around one of my web applications. I'd like to do the same thing for Windows (preferably in Ruby, but whatever is easiest).
Since this is not the core of the application, I'd rather not spend a lot of time trying to build and maintain it. I just need a Windows application that can:
Open a specific website on application launch using an embedded WebKit WebView
Trigger Growl notifications via JavaScript (with some sort of named bridge)
What is the easiest, fastest, cleanest way to do this?
Update: So far I've come across some frameworks like Qt and Awesomium. I don't know how these frameworks compare to other options available, so if you have any opinions or advice, I would appreciate it.
Check out http://appjs.org/ it's built with NodeJS at its core! And it uses chromium webkit at it's core :D
Well, this is a very old question, but if you are still interested...
I'd recommend Qt. There are some very good books available with a lot of boilerplate code and wizard-type tools. You will be able to find example code demonstrating the embedded Webkit that you can modify to suit your needs. It is free and redistribution is free (last I knew). You won't have to know anything about native Windows development, nor even use any native Windows dev tools.
Good luck!

How do I code applications on a Mac so that they use the native UI elements?

I'm starting to program. Already did some things with Java: a calculator, one document management system powered with a database and some other home projects. But I don't like the visual look. I love however how mi Mac's Apps look. And I want to create Apps for mac. Already buy one but when I open netbeans to program it looks like the Apps doesn't feel like mac.
Is there any specific java code to make the controls looks like how the other mac apps look? My dad mention something about Object C but I don't understand. Can someone please explain me.
AFAIK You'll never get the look and feel of Aqua (Mac's UI Kit) by using Java. Why? Because to make Java platform independent some things needs to get ripped off. And native controls are one of them.
I think you're taking about Objective C which is the native development language for building Mac Apps. I'll recommend you the book "Learn Objective-C on the Mac" is pretty useful.
P.S. I'll encourage you to start with iOS (iPhone and iPad apps). Why? Well, I think is easier to begin with. Things like fixed resolution and so on make your development efforts small while beginning with. (Just my 2 cents)
If you want to code in Objective-C, you'll first need to trek over to the App Store and download Xcode. This will install C/C++/Objective-C compilers on your Mac and then you can start getting your hands dirty.
Depending on what you are trying to accomplish, you can just google/read/learn and build your own frameworks from the ground up or look at something like Cocoa to get started as well.
http://developer.apple.com/technologies/mac/cocoa.html
Cocoa Frameworks
The Cocoa frameworks consist of libraries, APIs, and runtimes that form the development layer for all of Mac OS X. By developing with Cocoa, you will be creating applications the same way Mac OS X itself is created. Your application will automatically inherit the great behaviors and appearances of Mac OS X, with full access to the underlying power of the UNIX operating system. Using Cocoa with the Xcode IDE is simply the best way to create native Mac applications.
Good luck!
Apple has deprecated a lot of the Java support in OS X. It's possible to have a Java application integrated, but there are some annoying bits missing. See one of my questions demonstrating some issues with Java applications in the Dock. You would be better off using Objective-C instead, since Apple has lots of documentation and tutorials available.
You're thinking of Objective C. You can also do applications for Mac using C/C++ but as of late the "popular" language for Mac development is Objective-C. There are tons of tutorials and plenty of documentation to walk you through writing apps for both Mac and iOS.

Mac/Windows MIDI application programming language

What is the best programming language for writing MIDI-interactive musical application that would be run on MAC and on Windows?
I've written cross platform (Mac OS X and Windows) MIDI applications using C++. I used the RtMidi for MIDI I/O which was incredibly easy to get going (on every platform just it just worked out of the box). The advantage of C++ is that you can use native GUIs on each platform, but if you're not already into C++ I'd say a cross platform project is a pretty ambitious first project.
One possibility is .NET (C# or VB.Net), which runs on Windows (of course) and Mac (thanks to Mono). The downside is that .NET does not have any native support for MIDI, so you'd have to tap into two different native APIs for MIDI.
Java is another possibility, since it has a number of MIDI-supporting libraries available. Your UI is bound to look pretty terrible, though.
Python has substantial support for MIDI and runs on Mac and Win.
pygame.midi
PyPortMidi
PythonMIDI
pyrtmidi
For both mac and windows I would suggest Java. Midi is just a protocol so any language can do it. A good framework will speed things up a lot. Java has frameworks to work with Midi and other multimedia sources.
PortMidi is another popular cross-platform MIDI library. Qt is a nice cross-platform Framework, GUI and utility library.
It's an old thread, but nowdays you can use .NET. I mean official cross-platform .NET from Microsoft, not Mono. In this case I can recommend my library – DryWetMIDI. Its core part (working with MIDI files, processing MIDI data and so on) is cross-platform for any OS supported by .NET.
As for working with MIDI devices, this API supports Windows and macOS (that's what you need). Full documentation of the library availabale here: https://melanchall.github.io/drywetmidi. There you can find full API reference and help articles. For example, overview article on working with MIDI devices.
The library is distributed via NuGet package and can be installed via NuGet on both Windows and macOS.

How do you port a Cocoa/Mac application to Windows?

How do you port a Cocoa/Mac application to Windows? I mean how would you go about it? Assume the app was written with Objective-C and Cocoa, there's nothing fancy going on, no "engine" that could be factored out, etc.
Rewrite from scratch? I don't think there will be huge overlaps between the Mac and Windows codebases, right?
I have doubts about cocotron.
Its not clear from the cocotron website that cocotron is actually production ready yet. Id suspect that it would be possible to start new app development and use cocotron constantly to maintain and test windows builds on the go.
But to retrofit it into an existing project might be a much larger task. There are also no alternatives to cocotron - other than perhaps gnustep.
The practical approach to cross platform development involves developing the non gui components of your application, once, in C or C++. And then using a cross platform GUI library like QT - which is VERY good at generating and using native UI where possible or faking it where not. Please DO go to qt.nokia.com and download the latest build of QTCreator for windows and mac - See how the same QT application looks and feels very convincingly native on both platforms.
If QT doesn't provide a native enough solution, then you need to develop your GUI twice :- once in Cocoa, and once in Win32. The cocoa GUI would be in objective C of course, the Win32 GUI in C/C++.
Your non gui application code would - written in c++ - not be able to call Objective-C directly, but its not hard to write shim classes, implemented in .mm files - the provide a c++ interface, and wrap access to an objective c object or class.
You are also going to have to come up with an alternative to CoreData on windows - perhaps sqlite? Given that XCode has integrated support for the sqlite framework, and testing multiple code paths is, well, more work - perhaps dropping CoreData in favor of a common layer is a better approach?
The problem with Objective C is its very poor support on any platform that is not OS X. You can attempt to use the Cocotron, but I wouldn't consider it production ready yet.
For portability, a re-write is in order. With judicious use of standard C or C++ for the "core" of the application, you could still implement platform specific GUI code. If you don't like maintaining two GUIs, you can also try a toolkit such as Qt
Depending on which objects and framework you are using for your cocoa app, you might be able to get away with using gnustep, although the end result will probably look very weird to windows users, and the development environment might be a bit difficult to setup at first.
Are you aware of Cocotron? It looks like the project may have gone stale, but it's a good starting point anyway. It's a project to port Core APIs.
If your application is not cleanly separated (ie: a la MVC) then the only solution is a rewrite, I think.

How hard is it to get a Cocoa application to run on Windows?

In the wikipedia article on Cocoa it says:
There are also open source implementations of major parts of the Cocoa framework that allows cross-platform (including Microsoft Windows) Cocoa application development, such as GNUstep, Cappuccino, and Cocotron.
Yet when I looked into whether Mac application Tweetie was available for windows the developer had ruled it out:
Windows doesn't have Cocoa, the programming environment that Tweetie is made in, as such, it seems like a poor possibility.
I'd like to have an answer to point the Tweetie developers (and as a resource for other cocoa developers) which would tell them:
Which implementation is the most suitable for getting a cocoa app running on windows?
How much work is it likely to take to get the app running under windows?
How easy/hard is it to maintain a common code base for Mac and Windows?
(any other considerations I've missed?)
Of course if it would be too much work I'd like to know that too before suggesting it and potentially sending someone else on a fruitless search.
Don't forget:
“Major parts of the Cocoa frameworks” is not the same as “the entirety of the Cocoa frameworks”. Tweetie could be using something that's missing.
Tweetie could be (very probably is) using APIs from the non-Cocoa frameworks, such as Core Foundation, Core Services, Core Graphics, and Core Animation. A port of the Cocoa frameworks alone won't include any of these APIs, and even a more complete Mac-API-emulation framework will not include all of them.
These frameworks are eternally chasing Apple. Even if they catch up, they'll be instantly behind again as of the next Mac OS X release. Mac developers already put off using new APIs in new Mac OS X releases while they wait for users to upgrade to those new releases; now you're asking atebits to also wait for the other-framework developer to catch up to Apple again.
Any second implementation of an existing API will have bugs that the first implementation doesn't, and vice versa. These differences will cause development and support problems.
You're asking atebits to add a third platform to an application that already exists on two. Supporting one platform is a lot of work. Supporting two platforms is a hell of a lot of work. Supporting three? Now you're getting into big-company territory.
So, even with these Cocoa-like frameworks, the answer is: Hard.
Among GNUstep, Cappuccino and Cocotron, Cocotron is only possible choice to port a Mac application to windows.
Cappuccino is for web and GNUstep only runs on top of cygwin or mingw, which means the GUI looks nothing like native windows apps.
It is theoretically possible to build cocoa windows apps using Cocotron. However, the reality is that it is still very hard to use, and it is still quite limited in the Cocoa API.
Therefore, two possible solutions:
Try hard to remove the codes that are not supported by Cocotron in the original code base and do the cross compilation. Maintaining common code base will be painful.
Start a new GUI at all, no common code base. two choices here
Start a cross platform project with cross application framework such as Qt, or Java.
Start a windows only project. There are a lot of choices here, .Net WinForm application, MFC, etc.
There are Windows compilers for Objective-C (the programming language used to write cocoa apps). However, Cocoa includes the frameworks for presenting the GUI. These visual frameworks are specific to Mac OS X because they use OS X only windows and other controls. So someone would need to re-implement the controls in Cocoa to use Windows controls.
Also, I am fairly certain that Tweetie uses Mac OS X only technologies like Core Animation. This does not exist on Windows, so the nice animation effects present in the apps would have to be implemented in a completely different way.

Resources