macOS Advice for a new guy...

[macmusician.exe]

Hey guys,

I am a college student taking pre-engineering classes at a community college until I transfer to a university to get my degree in computer engineering with an emphasis in software engineering and also a minor in music technology. Basically, I hope to learn how to develop music production software. At this point I have taken classes just to get my general education classes done. This is my first semester learning code of any sort. I am in an "Engineering C/C++" class, that my instructor has said will barely touch the subject of C++, and also an "Introduction to HTML/XHTML/CSS" class (not for my major, but want to know web development also). I want to develop software that is presentable and essentially something that I can sell in retail stores one day. So, I have given you this background information to ask for advice and a few questions:

1) Where is the best place to start learning programming to get a head start on classes I will be bombarded with later in my college career? Can anyone suggest books, websites, videos, etc.? (I would like to begin learning on my own now.)

2) What programming language(s) would I most likely need to learn to create my own music production software?


3) If I want to develop this software on my Macbook Pro or iMac, what software is available for writing my program? What I hope to develop would need to be very clean and presentable, so the application used to develop the software must be able to take care of visual/GUI aspects as well.

4) Any other tips or hints...? Much appreciated!

 

[lee1210]

1) Probably a book. Look here: http://guides.macrumors.com/Cocoa_FAQ
2) For the Mac or iOS, Objective-C.
3) XCode. There are a few other options, but this is most likely what you'll use. It has a companion called interface builder for UI.
4) This is a frustrating process. If you really want it you can't give up when you get irritated. You have to stick with it. Also, learning some advanced math to be able to deal with audio processing would be a plus.

-Lee

 

[macmusician.exe]

1) Probably a book. Look here: http://guides.macrumors.com/Cocoa_FAQ
2) For the Mac or iOS, Objective-C.
3) XCode. There are a few other options, but this is most likely what you'll use. It has a companion called interface builder for UI.
4) This is a frustrating process. If you really want it you can't give up when you get irritated. You have to stick with it. Also, learning some advanced math to be able to deal with audio processing would be a plus.

-Lee

Lee,

I appreciate your answers and tips. Thank you! In response to number four, my major requires Calculus I, II, III, Differential Equations, and Statistics. I should have a good understanding of the mathematics I will need for audio processing, provided I attempt to do better than just pass these classes.

Another question that I thought of: Being as I am such a newbie to this, does writing a program in Objective-C mean I will have to write entirely different code for my software to run on Windows? What do developers do when they offer software that runs on both?

Thanks again, much appreciated!

 

[jiminaus]

Being as I am such a newbie to this, does writing a program in Objective-C mean I will have to write entirely different code for my software to run on Windows? What do developers do when they offer software that runs on both?

There's a difference between a language and the libraries of code that you use when you code in a language.

For example, Objective-C is a language. When you code for Mac OS X, you use the Cocoa library together with the Objective-C language. Similarly when you code for iOS, you use the Cocoa Touch library together with the Objective-C language.

When you code for Windows, you have many more choices. Examples include using the C# language with the WFC library and the C++ language with the MFC library.

Often the core language will work across platform. Whether your code will compile cross-platform will largely depend on whether the libraries you've coded against are cross-platform.

There is a (partial) implementation of Cocoa for Windows called GNUStep. So it is theoretically to take your Mac OS X code and make a Windows app.

However, mostly if people are creating cross-platform applications, they start off with cross-platform libraries. For example, coding in C++ using the wxWidgets library, or coding in Java using the JFC library. The trouble with this approach is that more often than not these kinds of apps feel foreign on Mac OS X.

Another technique is to isolate your application's business logic from its user interface. You code your business logic in a neutral language using cross-platform libraries. And then you code a user interface for Mac OS X using Objective-C/Cocoa and you code another user interface for Windows using, for example, C#/WFC. The VLC player is a good example of this technique. There's a design pattern called Model-View-Controller (MVC) that is commonly used to do this (and is a good idea for other reasons too).

 

[macmusician.exe]

There's a difference between a language and the libraries of code that you use when you code in a language.

When you say libraries of code is that what would be included in an "include statement", such as #include <stdio.h>?

And from what you said, it sounds like writing a second program for Windows would be the best option, correct?

I got a little confused when I was reading the last paragraph of your post. Can you explain what you mean by a "neutral language" and "isolating your application's business logic from it's user interface"?

I apologize for my lack of knowledge. These questions are probably extremely idiotic to most of you! Thank you for your help though.

 

[Sander]

Most software can be split up in the part that does the actual work (calculations, data processing, etc.) and the part that performs the user interaction (asks for input, displays results, etc.)

The latter part is usually highly platform-specific, whereas the former part is specific to your application and can usually be kept platform-agnostic.

So you write the core of your application once, making sure to keep it platform-independent (for example, by using only C++ and standard libraries) and write specific GUIs for each platform you want to deploy on.

There are other approaches where you can use a library which "wraps" the platform-specific stuff (such as Qt), so you only need to write that part once as well - but usually the "user experience" when using such libraries is not perfect since it often doesn't behave exactly as a native application.

For stuff like games (which take over the entire computer anyway) and really simple input/output ("type the amount in dollars here and I'll display the equivalent value in euros") that's not too bad, but for everything in between, there are sometimes small glitches (not handling drag&drop like a native app would, etc.). So beware.

 

[thundersteele]

1. Programming languages:
Everyone has to start somewhere. But eventually, the language becomes secondary - once you know how to design programs and algorithms, you just choose the language that makes it easiest to implement for the current project. Most computer science degrees use a large variety of languages - the goal is to teach you how to write a good program, not to learn a specific language.

To start:
Python or another scripting language is nice for learning python.org for manuals, tutorials, etc
C/C++ are very widely used. Can be a bit confusing to learn
Java is nice, because it's platform independent.

2. Platforms
As mentioned above, programming languages are (mostly) platform independent. Nevertheless, many platforms have their preferred frameworks, e.g. Objective C/Cocoa for OSX programs. The advantage is that it is very easy to implement a program that looks nice and interacts easily with other OSX programs. The downside is that the programs are hard to port - you mostly have to start from scratch.
There are a few options to circumvent the portability problem:
a) use a platform independent framework, e.g. Java or Python, OpenGL instead of DirectX, etc.
b) write good, modular code - e.g. you could probably write most classes or functions for a program in a way that they don't depend on the operating system - then you just have to rewrite small portions of the code, e.g. the user interface or the parts of the program that access the hardware

3. For OSX applications, Xcode is the tool of choice. Makes GUI programming very simple.

4. Don't give up. Work through tutorials, then find yourself some small projects and try to finish them. Have fun!

 

[macmusician.exe]

1. Programming languages:
Everyone has to start somewhere. But eventually, the language becomes secondary - once you know how to design programs and algorithms, you just choose the language that makes it easiest to implement for the current project. Most computer science degrees use a large variety of languages - the goal is to teach you how to write a good program, not to learn a specific language.

To start:
Python or another scripting language is nice for learning python.org for manuals, tutorials, etc
C/C++ are very widely used. Can be a bit confusing to learn
Java is nice, because it's platform independent.

2. Platforms
As mentioned above, programming languages are (mostly) platform independent. Nevertheless, many platforms have their preferred frameworks, e.g. Objective C/Cocoa for OSX programs. The advantage is that it is very easy to implement a program that looks nice and interacts easily with other OSX programs. The downside is that the programs are hard to port - you mostly have to start from scratch.
There are a few options to circumvent the portability problem:
a) use a platform independent framework, e.g. Java or Python, OpenGL instead of DirectX, etc.
b) write good, modular code - e.g. you could probably write most classes or functions for a program in a way that they don't depend on the operating system - then you just have to rewrite small portions of the code, e.g. the user interface or the parts of the program that access the hardware

3. For OSX applications, Xcode is the tool of choice. Makes GUI programming very simple.

4. Don't give up. Work through tutorials, then find yourself some small projects and try to finish them. Have fun!

I have an idea of what program I want to create and this program I will be making will run as a plug-in in multiple digital audio workstation (DAW) programs (such as Logic Pro, Pro Tools, and Ableton). It would also need to run as a stand alone program. Do I need to worry about how the program it would run within is coded?

Secondly, does anyone know if the audio related thread section has music related programmers? If there are any music related programmers I would like to speak with them! Thank you!

 

[lloyddean]

Haven't written any of these plug-in's since 2008 but you'd probably want to write a plug-in (Audio Unit usable with all DAWs listed) and a shell program of your own that uses the plug-in.

 

[macmusician.exe]

Haven't written any of these plug-in's since 2008 but you'd probably want to write a plug-in (Audio Unit usable with all DAWs listed) and a shell program of your own that uses the plug-in.

Does that mean it would need to be DAW specific as well as Mac/Windows specific?

Which would mean two programs per DAW (one Mac, one Windows) times "x" number of DAWs plus two stand alone programs (one Mac, one Windows)?

2x + 2 = F My Life, where "x" equals an integer greater than 4.

I hope it's a bit more simple to do than to write code for that many variations of the same program.

 

[Sander]

If you're writing plugins, then I would expect that they are application-dependent. Unless the plugins are somehow standardized across applications (such as VST plugins, I think), every application expects a different set of functionality if its plugins.

But maybe it's not so bad. It would be quite likely that the application the plugins are for also offers some functions for the plugin as well, specifically to render the UI for the plugin. In that case, chances are that you can use one set of code for that application across different platforms.

 

[lloyddean]

Let's ask the question - does your plug-in require a GUI?

 

[firewood]

The guts of most music production software is probably written in C or C++, and Objective C on a Mac is a pure superset of C. You can easily write Mac apps that have Objective C UIs wrapped around portable C DSP/music code. But you will most likely have to end up learning a variety of programming languages as well as a lot about writing portable code in this general field.

If you want to be good at music DSP, don't just pass your courses on advanced calculus and the algebra of complex variables, but really understand and get a good feel for the stuff. Consider adding side courses on numerical analysis, music theory, physics and human psychology as well.

 

[chrono1081]

I don't know how music plugins may work for your programs but I know for Maya plugins you use Maya's API (NOT MEL, they're different) and develop in C++.

For the GUI Maya has its own built in set of functionality with menu's buttons, and such. I can write a plugin on Mac and it'll work in Linux and Windows as well.

Perhaps the program you plan on writing for has this same functionality.

 

[lloyddean]

The API's have likely been updated since I last did anything but last I did they were all C++ based frameworks. These frameworks each had there own graphics "native" event handling and graphics system.

Single source development was possible with platform specific abstraction layers between the DAW frame works and your graphics rendering, interaction and audio processing routines. It took knowing both platforms Mac OS and Windows and becoming familiar with each of the DAW APIS on both platforms in order to write something that could be done from a more, or less, single code base.

It was obviously a learning experience, difficult and required dedication but it could be done making the task easier in the long run.

 

[subsonix]

For Mac, the obvious starting point is probably AU which is part of Core Audio. Then you are compatible with Logic, Garage band and Digital Performer and others. The core of your plugin (the pure DSP) can probably be made reasonably portable in C, which you then can plug into different frameworks.

 

[thekev]

For the GUI Maya has its own built in set of functionality with menu's buttons, and such. I can write a plugin on Mac and it'll work in Linux and Windows as well.

It will? I've noticed many are only available on Windows. I figured this meant porting was complicated for such a plugin.

 

[jiminaus]

It will? I've noticed many are only available on Windows. I figured this meant porting was complicated for such a plugin.

There's just potential portability. There may be other code in the plugin that make's it Windows only.

Or it could simply be that the plugin developer just hasn't compiled the plugin for Mac.

 

[chrono1081]

It will? I've noticed many are only available on Windows. I figured this meant porting was complicated for such a plugin.

Its not a guarantee but its how it works with Maya, I'm not sure if it'll work with the program you are trying to use.

 

[lloyddean]

The Maya "problem" is one of perception, lazy programmers mostly and of lousy marketing staff (my experienced opinion).

 

[thekev]

There's just potential portability. There may be other code in the plugin that make's it Windows only.

Or it could simply be that the plugin developer just hasn't compiled the plugin for Mac.

Yeah that makes me sad

 

[chrono1081]

The Maya "problem" is one of perception, lazy programmers mostly and of lousy marketing staff (my experienced opinion).

Don't forget lazy documentation writers Maya's docs are out of date, or missing info. Thankfully the example programs are up to date.

 

[macmusician.exe]

So if I understand this correctly, it will be possible to write code for each set up, Windows or Mac, and one for each DAW, but basically the majority of it will have been done the first time and there will be little to change and/or add for each new variation of the program?

I know this will take me a long time and I will need to learn several other bits of information along the way. That is why I want to begin now and that's also why I will be saving all of my textbooks. I hope to take my time with this and release it as a great, quality program. I will be developing software to sell, so it needs to look as "pretty" and be as user friendly as possible. I just hope I can get this finished before I'm 25!

 

[jiminaus]

it needs to look as "pretty" and be as user friendly as possible.

No to the former. Yes to the later.

If you're writing plugins, have the plugin integrate with the rest of the host application; but otherwise focus on good user experience (= user-computer interaction = user friendly; the term has evolved).

Don't be Microsoft and focus on "prettiness". Things like graphics, gradients and animations should be added because they directly help someone understand what will/is/did happen in your plugin; not for show, not to be pretty.

 

[macmusician.exe]

No to the former. Yes to the later.

If you're writing plugins, have the plugin integrate with the rest of the host application; but otherwise focus on good user experience (= user-computer interaction = user friendly; the term has evolved).

Don't be Microsoft and focus on "prettiness". Things like graphics, gradients and animations should be added because they directly help someone understand what will/is/did happen in your plugin; not for show, not to be pretty.

I guess I didn't word that correctly. I meant for user friendly and "pretty" to go together. I don't want it to just look nice. It needs to look nice because it is easy to use.