# Learning to Program C++ or other Language for Music?



## José Herring (Nov 3, 2014)

Hi,

I'm considering learning a programming language to write music software. There are so many things that I have ideas for but yet the products don't exist or cost thousands to implement. 

I remember RC had a guy that did custom programming for Hans. So I figured, HOW HARD COULD IT REALLY BE?! :D 

But, I must admit that I'm having trouble getting started. 

For those in the know, should I just start by learning C++, or should I use a language specifically designed for music like Juce or something similar? I've decided that I want to stay away from CSOUND or programs like synthedit or what have you. But Max, might be a decent one if I can make VST programs from it.

Mind you, this is for my own use and not for any commercial purpose.


----------



## pmountford (Nov 3, 2014)

While I don't have any experience of VST or sound programming, I was a C++ programmer for several years (before turning to music) and would suggest that you're certainly giving yourself a challenge if this is your first route into programming! It's not what I'd call the friendliest of languages to start programming with. However, things may have changed a little since I last used it (over a decade ago..) and of course I don't know whether you're already familiar with programming and object orientation?


----------



## José Herring (Nov 3, 2014)

I took some programming classes in College. Can't say that I was any good at it, but I wasn't really motivated to be. As far as Object orientation, I have no experience with it. 

As far as challenge, I don't think I'm really concerned with that. I don't need to be up and running in anytime soon and my life isn't going to depend on learning to program. I'm just tired of always waiting around for somebody to come up with the things that I need only to find out that what they come up with only partially does the job. 

I suspect that as I get more money, I'll probably hire somebody, but since I'm the only one now, it's going to have to be me


----------



## pmountford (Nov 3, 2014)

Sorry, I've realised I'm not being that helpful and I'd never try and persuade anyone NOT to try something, it's just that I wonder if there are any alternative languages to start with? But if/when you get a problem there's a wealth of general programming sites that can be of help. Don't mind helping with any syntax questions myself if I can get the grey matter working in C++ again after so long..!


----------



## José Herring (Nov 3, 2014)

Oh, I didn't take your post as discouragement. I think you're being honest. I always say if something is easy then everybody would be doing it. 

I'm thinking of Max but I'm not sure if it would be the right thing. I fooled around with it in the past and it seems to be able to do somethings that I need. I know that I could programming a control surface with it. But, I don't think that I could do audio over ethernet protocols or such. But, I may just start with trying to do a control surface in the language (or lack of language ).

Here's a link to Max, what do you think? http://cycling74.com/


----------



## pmountford (Nov 3, 2014)

Very interesting. Something I know nothing about so I'm not sure whether Max is used to create standalone code/programs (I presume it is) or whether it's just an environment (I presume not). 

I might suggest start by looking for any tutorials similar to what you want to create and then use whatever language/tools are used in the tutorials? Just an idea. So obvious it's probably of no use!


----------



## Adrian Myers (Nov 3, 2014)

Jose (OP),

In a choice between C++ and Max, it really depends on what specifically you would like to accomplish and how much time you would be comfortable spending programming.

Max seems to me to be at the opposite end of any spectrum that includes C++. The former is effectively a scripting language that runs within a proprietary environment and is strongly oriented towards music and audio processing, while the latter is as close to machine code as most programmers have any reason to get and is completely general. A very coarse, general reaction is that you'll probably learn significantly more working in C++, but you would need a lot more time to build your first application. But after becoming proficient in C++ (which is not going to happen overnight), you'll be able to write things in it quickly.

Also, pretty much any modern language can work with MIDI or audio data, and some very generous people have made libraries to help you write VST compatible applications in a variety of languages. You can see a C++ VST guide here: http://teragonaudio.com/article/How-to- ... tudio.html, which for example also links to a C# guide here: http://vstnet.codeplex.com/

I write mostly C# now, after writing games in a variety of languages including C++, and I would probably be more likely to recommend C# than C++ to someone new to programming. However, Steve Duda rather famously taught himself C++ straight out of some VST tutorials and wound up writing some of the most impressive and thoughtful software around.

It's a tricky thing. Some people really just want to build a couple specific tools and get back to another task other than tool-building, and for them, the deep waters of something like C++ are a waste of time. But for others, understanding the fundamentals of a field is inspirational itself and will give them enthusiasm well beyond what a couple productivity toys would, and so they are better off starting at the deep end and taking advantage of the momentum they get from being challenged.

Either way, this looks like a fantastic resource: http://musicdsp.org/archive.php?classid=1

If you wanted to get to the low-level stuff like writing your own oscillator or picking a specific fast fourier transform implementation, you're probably going to find a lot more code written in C++ than anything else (although that link above does have some cool stuff in unusual languages!).

If you do go for C++ though, or even think you might, I would recommend going deep quickly and getting right to work. Programmers have holy wars you would not believe, and it's easy to get lost reading incredible amounts of total horseshit instead of doing interesting work, which could probably be done in just about anything, in theory. I'd say more here but then it would just be part of that problem, wouldn't it


----------



## TGV (Nov 3, 2014)

If you want to *learn* how to program, start with Python. It's friendlier than C++, and there are quite a few tutorials and online courses available, and it has a ton of libraries for anything from gene sequencing to sound processing. It will teach you programming, OO, and a few other things, and let you build software without the burden of C++ (syntax, declaration, memory management, ...).

If you want to build your own plugins, that's a different story. Plugins are usually a bit more limited in what they can do, as they have to fit the sequencers audio/midi signal flow, and require careful programming to get a decent performance, and that's where C/C++ comes in. It is hard for the novice programmer. I'd say it's even hard for an expert programmer. So that's the path if you really want to make a commercial grade plugin.

There are other environments like Max. Reaktor can do similar things, PureData (pd, a max clone) too. One that can generate plugins is SynthEdit, now being taken over by FlowStone, but you said you want to stay away from that. Juce is a framework (a library like thing that wraps around your code) for C++; it doesn't do anything, it's just a template for a VST plugin without the signal and midi processing. If you know C/C++, and you want to write a VST plugin, Juce is a good start.

So what is it you want to build? Can it run offline? If not, does it have to run inside a sequencer or can it run in parallel?


----------



## rgames (Nov 3, 2014)

The choice of language doesn't really matter, though I doubt something like MAX makes much sense - you need one of the standard languages. However, even if you learn a language, doing so has nothing to do with learning how to program. There is so much more - data structures, memory access, functional structures, etc. - that has nothing to do with any given language. They're basic concepts in computer science.

It's like physics: you can do physics in German or English or Italian or whatever. The language is different, but the concepts are the same. You need to learn a language in order to express the concepts but those concepts must be learned independent of the language. Likewise in programming, there are a *lot* of basic concepts that must be learned in order to write even a mildly complex application.

Even beyond that, though, you add another level of complexity when you start to do real-time programming as you would for an audio application. If you're writing a word processing application then real-time considerations don't come in to play, but to write any kind of audio application you need a pretty deep level of understanding of how computer hardware *actually* works (i.e. not just what motherboard goes with which processor). For example, you need to know what registers are and how to access them, you need to understand what buffer transfers are and how they are executed, you need to understand how to deal with system timing, etc.

I'll bet that most major audio apps have a team of assembly language geeks on their staff - based on my programming experience, you need that kind of register-level programming in order to make a real-time application work worth a darn.

If you want to make a new audio app I'd say the best bet is to focus on the big picture and hire a team of programmers to deal with all those details.

rgames


----------



## FriFlo (Nov 3, 2014)

I would recommend Max, if you are interested in creating your own stuff. Within limits, you can even get it out to other people, but writing a program from scratch is something more advanced. I am interested in this path myself, but at some point I realized, programming is a full time profession. Be prepared to have no time for music left, if you really want to commit to it ...


----------



## José Herring (Nov 3, 2014)

Thanks for the input guys!

I'm thinking in the order of like 2 years to take it a bit at a time for C++.

I'll look into C#. Never heard of it before.

I do want it for specific tools, not more than that. Basically I'd like a graphic based midi controller for a touch screen. Also, I'd like to find a way to write my own audio over ethernet protocol. I found this interesting program for that by Audinate, but it requires you to have Dante enabled hardware and I started thinking there was a way to go straight ethernet to ethernet port. 

Apart from that I have a few ideas for VST plugins that I need. Things to make things easier for me and save a few steps in sounddesign. Max might actually be able to do it for the plugins. I have to look more into it.


----------



## José Herring (Nov 3, 2014)

So I checked out Puredata and will probably start there to see if I can get a midi touchscreen controller from it. Then I'll check out C# and see if it's a little less daunting than C++.

Thanks for the help.


----------



## wst3 (Nov 3, 2014)

If you want to learn programming - general programming rather, then I'd recommend starting with an interpreted language, it makes the learning process so much easier. I'd suggest PERL, which has a lot of libraries you can use to do things basic MIDI and audio processing, and even touch screens. PERL can be object oriented or procedural, and while I did it backwards (PERL did not exist when I was in school) I think PERL would be a wonderful precursor to both C and C++.

PureData (PD) is a very cool environment to learn about processing audio or MIDI data - but I don't think I'd recommend it as a way to learn programming.

Sonofagun - there is a PERL library that talks to PD!

Yes, I think PERL and PD would be a good starting point.


----------



## Gerhard Westphalen (Nov 3, 2014)

josejherring @ Mon Nov 03 said:


> Thanks for the input guys!
> 
> I'm thinking in the order of like 2 years to take it a bit at a time for C++.
> 
> ...



I had the EXACT same thoughts this summer. I experimented with different audio over ethernet solutions but nothing worked well. Waiting for Dante Via to be released. 
For a touchscreen I just run Emulator Pro but I wanted to make my own program similar to what Mark Wherry did. 
I picked up a book for starting out with C++ but so far I'm nowhere near knowing anything remotely close to a touchscreen controller software or anything involving ethernet. It'll take me a lot longer to learn than I thought but I plan to take some computer science courses (maybe even a major if I can fit it around my other degree) over the next few years which will hopefully help. 
I picked up a book on designing VST plugins with C++ but you sort of have to work around a template software so you don't actually do that much. I'm still not done reading that one so it may go into more detail.


----------



## Ozymandias (Nov 3, 2014)

In addition to the other suggestions, Reaper's JSFX might be worth looking at. There is a ton of existing code to look through and a helpful forum. And there's a JS-VST wrapper (ReaJS), so you can use your creations in your preferred DAW.

It's not the most intuitive of languages, but it's certainly a lot easier than building stuff from scratch.


----------



## Mike Greene (Nov 3, 2014)

These are some great responses! I have a few questions of my own, which I think coincide with Jose’s.

Tell me if I have this straight: If someone writes code in C++, then they’re going to be able to use it in any OS. Of course, they’ll have to compile it for each platform, and conform to whatever platform-specific restrictions might apply to a particular OS (size of GUI, for instance, if it’s an iOS app), but if an app is written in C++, then you expect it will be cross-platform. Am I correct with this?

Now (still flying blind here,) there are these “frameworks” for C++, like JUCE and Qt, that supposedly make programming easier. I presume because they have shortcuts that make it so you don’t have to be as nitty gritty with every coding detail as you would if you were writing code in C++.

(Still presuming . . . ) To program in Qt or JUCE, one would first need to learn C++. So Qt or JUCE aren’t necessarily easier to learn, they just come with handy “toolbags,” so that a programmer doesn’t have to re-invent every wheel when coding in C++. Like maybe there’s a “read wave file” command in JUCE that would have to be written by hand in C++. (Again, please correct me if I’m wrong.)

So lets suppose I’m not as brave as Jose, and rather than trying to learn a new language, I want to _hire_ someone to write an app for me. Specifically, an ultra-rudimentary sequencer, where the user can draw notes (blobs) onto a piano roll. Internally, there’s no audio, just straight numerical data for the MIDI notes. What language would I request the programmer code in? Would I specify Qt or JUCE, or should I leave C++ as an option? Would JUCE have more shortcuts, thus making the job cheaper?

Or lets suppose I want to write a second app. This one would do Fourier Transforms on audio files. Then “do a bunch of stuff” with that data. Would JUCE already have FFT modules that make this job easier?

Finally, lets suppose I _might_ be as brave as Jose and try to learn Qt, JUCE, and/or C++ and write these two apps myself. (Which I plan to sell, which is why cross-platform is so important.) Which language(s) should I learn?


----------



## kb123 (Nov 3, 2014)

A lot of ground covered in this thread, and there are so many options and so many variables depending on what it is that you want to do, that its really impossible to give a simplistic answer.

The first thing I would do is head over to forums such as the dsp forum at KVR http://www.kvraudio.com/forum/viewforum.php?f=33. Its a huge resource with very knowledgeable people who have actually successfully done these things.


----------



## Musicologo (Nov 3, 2014)

Since Music is mainly a symbolic language then LISP beats all other languages in that respect, because it's naturally more prone to deal with Symbolic manipulation with maximum flexibility. There are many "Lisp based environments" like Common Music (http://commonmusic.sourceforge.net/), Symbolic Composer (http://www.symboliccomposer.com/) or the recent Opus Modus (http://opusmodus.com/).

Also another completely different alternative, also free, is Super Collider (http://supercollider.sourceforge.net/) in terms of sound manipulation.

So, there you go, more suggestions to add confusion into the pot xD


----------



## José Herring (Nov 3, 2014)

I'm overwhelmed. These are great responses that would take me far too long to respond to, so a big thanks to all.

I'll have to take baby steps. And, just building the first project I think can be done with Puredata or Max. So I'll start there before I start tackling a language.

Curious to know though, if there are so many languages and some of them are more friendly towards music, then why do so many software devs use C++? Are there plugs out there written in another language like LIPS or Perl or C# that make it to professional productions?


----------



## rgames (Nov 3, 2014)

josejherring @ Mon Nov 03 said:


> why do so many software devs use C++?


Performance.

Most of the high-level languages have canned interfaces to video, audio, and other hardware elements but they're not very good at anything other than basic tasks. C++ can be as high-level or as low-level as you like (you can even do inline assembly in most compilers, I believe). For example, you can use WPF in C# to get at the standard windows 3D graphics routines but they're not really usable for a demanding application like 3D modeling or a game. You need to write in C++ (and assembly, most likely) with direct links to OpenGL or DirectX to get the performance those apps need.

My guess is that you'll find the same limitation with the audio interfaces - probably fine for simple tasks but odds are you'll quickly stress them past their breaking point and have to dive deeper into a purpose-written interface in a more powerful language.

rgames


----------



## Reegs (Nov 3, 2014)

Mike Greene @ Mon Nov 03 said:


> These are some great responses! I have a few questions of my own, which I think coincide with Jose’s.
> 
> Tell me if I have this straight: If someone writes code in C++, then they’re going to be able to use it in any OS. Of course, they’ll have to compile it for each platform, and conform to whatever platform-specific restrictions might apply to a particular OS (size of GUI, for instance, if it’s an iOS app), but if an app is written in C++, then you expect it will be cross-platform. Am I correct with this?



Yep! It's called the compiler's target. Writing general "command-line level" programs is very platform agnostic, with only a few tweaks needed. GUI stuff, not so much.



> Now (still flying blind here,) there are these “frameworks” for C++, like JUCE and Qt, that supposedly make programming easier. I presume because they have shortcuts that make it so you don’t have to be as nitty gritty with every coding detail as you would if you were writing code in C++.



Exactly. Among other things, JUCE and Qt abstract the system calls to manipulate the windowing systems. Instead of making these calls directly, you use functions they define to set buttons and widget behavior. At compile time they link to the proper system calls based on the target.



> (Still presuming . . . ) To program in Qt or JUCE, one would first need to learn C++. So Qt or JUCE aren’t necessarily easier to learn, they just come with handy “toolbags,” so that a programmer doesn’t have to re-invent every wheel when coding in C++. Like maybe there’s a “read wave file” command in JUCE that would have to be written by hand in C++. (Again, please correct me if I’m wrong.)


You continue to presume correctly  JUCE has a very convenient set of basic audio manipulation functions built in.

And actually you don't need to know C++ to use Qt. It has a number of language bindings, which is to say that someone else has gone to the trouble of making wrappers so you can use its functions in Python, Haskell, and other languages.



> So lets suppose I’m not as brave as Jose, and rather than trying to learn a new language, I want to _hire_ someone to write an app for me. Specifically, an ultra-rudimentary sequencer, where the user can draw notes (blobs) onto a piano roll. Internally, there’s no audio, just straight numerical data for the MIDI notes. What language would I request the programmer code in? Would I specify Qt or JUCE, or should I leave C++ as an option? Would JUCE have more shortcuts, thus making the job cheaper?



I'd tell them to use a standard language. C++ if you're planning for app development is probably your best bet. Other options would be a hodgepodge of Objective-C (iOS) and Java (Android). With the right compiler, Windows can handle most code languages you can throw at it.

JUCE will very likely speed development time because it has implementations for almost everything you need for audio and midi work. I don't know if I'd hard-spec it before hearing the programmer's planned architecture, but I'd definitely mention it as an option to use during the pitch. (Note that commercial use of JUCE does require a commercial license to be purchased for a few hundred bucks.)



> Or lets suppose I want to write a second app. This one would do Fourier Transforms on audio files. Then “do a bunch of stuff” with that data. Would JUCE already have FFT modules that make this job easier?



I don't think JUCE has FFT or spectral decomposition built-in (but it does have a ton of filters and processors: see http://www.juce.com/api/hierarchy.html ) For FFT specifically, one popular library that comes to mind is FFTW, which is GPL'd, but also has a licensing option for commercial use.

Depending on your actual processing, you may not actually need to take the FFT of the signal. Many compression and EQ processors, as examples, are little more than a set of multiplications by a coefficient on each sample.



> Finally, lets suppose I _might_ be as brave as Jose and try to learn Qt, JUCE, and/or C++ and write these two apps myself. (Which I plan to sell, which is why cross-platform is so important.) Which language(s) should I learn?



C++ if you want to use JUCE and Qt and many other audio oriented libraries out there.


----------



## rgames (Nov 3, 2014)

Mike Greene @ Mon Nov 03 said:


> Tell me if I have this straight: If someone writes code in C++, then they’re going to be able to use it in any OS. Of course, they’ll have to compile it for each platform, and conform to whatever platform-specific restrictions might apply to a particular OS (size of GUI, for instance, if it’s an iOS app), but if an app is written in C++, then you expect it will be cross-platform. Am I correct with this?


That's the dream! Alas, it is not the reality, especially if you're dealing with video and audio.

There are all sorts of screwey things that different OSes do with the same code - time and date functions are different, handling of text is different, lots of things are different that you would think are rudimentary and the same across all platforms. When you code with cross-platform in mind, you add compiler directives that tell it "Compiler - use this if it's for Windows. <code> Otherwise, use this. <more code>" But even then it gets tricky because you don't always catch everything and different compilers respond differently to the directives.

I'm a proponent of do-it-yourself for a lot of things but coding even moderately complex apps for video/audio is not one of them (speaking from experience here...). It'll suck up a lot of your time just trying to learn all the secret handshakes. If you have a vision, hire a programmer.

rgames


----------



## Reegs (Nov 3, 2014)

rgames @ Mon Nov 03 said:


> josejherring @ Mon Nov 03 said:
> 
> 
> > why do so many software devs use C++?
> ...



+1

Also, with specific regard to VST plugins, the Steinberg VST SDK is only available for C++ and Delphi. So that sort of limits your options by erecting an ease-of-use barrier linking to other languages. Though as Richard alluded, most of the vst:rocess() code (the stuff that actually does near-realtime math on your audio) lives in very specific handwritten assembly code.


----------



## tonecarver (Nov 3, 2014)

Programming a musical app/effect/instrument can be hugely rewarding but can take (usually does take) immense amounts of time and diligence to bring a vision to completion. Learning general C++ programming can be a significant learning curve, learning to program signal processing applications is another learning curve on top of that. 

That said, if you are ready and willing to dig in, here is an excellent tutorial on using freeware tools to build some great starter plugins: http://martin-finke.de/blog/tags/making_audio_plugins.html

There's also this book which seems like an excellent resource -- I do not have the book, so cannot offer much of an opinion, but it seems like it might be a good resource for someone starting out: http://www.amazon.com/Designing-Audio-Effect-Plug-Ins-Processing/dp/0240825152/ref=sr_1_2?s=books&ie=UTF8&qid=1415073815&sr=1-2

And, here is a thread at KVR with lots of tips and pointers for getting started:
http://www.kvraudio.com/forum/viewtopic.php?t=329696

So, it's work, probably a lot of it, but it is pretty cool to learn some new technology and see one's ideas realized (after working through the inevitable bugs and hurdles). :wink:


----------



## marclawsonmusic (Nov 3, 2014)

Hi Jose, 

Just curious... What is your goal?

Do you want to write DAW plugins? Do you want to write Kontakt instruments? Do you want to write standalone software programs?

Sadly, the responses on this thread are about as varied as if you asked "hey guys, what is a good strings library to use".

But the (right) answer remains the same - your goal will dictate the tool.

PS - The closer you get to interacting directly with hardware, the more complicated / difficult the language will be. C++ can interact directly with hardware (drivers are written in C++), so it is quite complicated. Contrast this with JavaScript, which is used in every web browser, and is alot easier to learn.

To Mike Greene - although C++ is used by pretty much every operating system, there are platform-specific concerns that must be addressed. So code written in Windows is not always directly portable to Mac OSX or Unix... or vice versa. It really depends on what that code does.

Oh, and C# is a terrific language. I use it almost daily. However, it is a higher-level language than C++ and might not be suited for what you are trying to do... again, we're back to the original question - "what is your goal?"

Marc


----------



## marclawsonmusic (Nov 3, 2014)

Reegs @ Mon Nov 03 said:


> > So lets suppose I’m not as brave as Jose, and rather than trying to learn a new language, I want to _hire_ someone to write an app for me. Specifically, an ultra-rudimentary sequencer, where the user can draw notes (blobs) onto a piano roll. Internally, there’s no audio, just straight numerical data for the MIDI notes. What language would I request the programmer code in? Would I specify Qt or JUCE, or should I leave C++ as an option? Would JUCE have more shortcuts, thus making the job cheaper?
> 
> 
> 
> I'd tell them to use a standard language. C++ if you're planning for app development is probably your best bet. Other options would be a hodgepodge of Objective-C (iOS) and Java (Android). With the right compiler, Windows can handle most code languages you can throw at it.


If you are going to hire a programmer, you should hire someone competent enough to tell YOU the best language to use for your project.

Telling an experienced programmer what language to use is like a director hiring a composer and telling them which sample library to use. It's silly. 

Any programmer who lets a customer dictate their toolset will probably do a shitty job anyway.


----------



## José Herring (Nov 3, 2014)

Hi Marc,

The goal is simple I guess, at least in idea. My first goal is to build a touchscreen GUI much like HZ has that I can customize to my individual needs which would include sliders and buttons for shortcuts and a transport. Kind of like this: http://www.kvraudio.com/forum/viewtopic.php?t=317998

The next goal is to create a simple and lean no bloat audio over ethernet app kind of like audinate but with no need to use hardware. 

The last goal would be just to create multi-fx in chains that I can use in sound design. I guess Max and perhaps Puredata can do this fairly well.

Thanks,

José


----------



## marclawsonmusic (Nov 3, 2014)

josejherring @ Tue Nov 04 said:


> The goal is simple I guess, at least in idea. My first goal is to build a touchscreen GUI much like HZ has that I can customize to my individual needs which would include sliders and buttons for shortcuts and a transport. Kind of like this: http://www.kvraudio.com/forum/viewtopic.php?t=317998


What do you want to run this on? An iPad? A Windows tablet? Android tablet? That will dictate the language to use.




> The next goal is to create a simple and lean no bloat audio over ethernet app kind of like audinate but with no need to use hardware.


Is there some reason you do not want to use VEPro? Because learning to program socket-layer asynchronous network software that has to sync with a master clock is not for the faint of heart! I have been programming for more than 20 years and there is no way in hell I would ever want to tackle that problem. Martin and the guys at Vienna have pretty much nailed that one. It's really *REALLY* complicated shit. No kidding.




> The last goal would be just to create multi-fx in chains that I can use in sound design. I guess Max and perhaps Puredata can do this fairly well.


If you are going to develop plugins, C++ is definitely the way to go. However, it is really complicated. There are some basic programming concepts that are hard to grasp if you jump right into C++. Mainly because C++ requires that you deal with lower-level tasks (like memory management and garbage collection) that are not required with higher-level languages. It's like learning to deal with an entire orchestra when you don't even know what a Gm chord is. Learning some basic object-oriented programming concepts - maybe in C# or Java / JavaScript - would be a good place to start before you dive headlong into C++. Writing in higher-level languages is like doing a sketch on the piano... writing in a low-level language like C++ is like writing for full orchestra... on paper. You gotta learn to walk before you can run.

Feel free to PM me anytime with questions.
Marc


----------



## José Herring (Nov 3, 2014)

Thanks for your input. Windows Touch screen or Linux for the touch controller. Linux rather than Windows for reasons I'll explain later on down this post. 

I use VEPro but I find it limited in that it will only stream so much audio before it does a bunk. I figured it's because it has so many other functions as well, vst hosting, mixing ect... Audinate is just a straight up virtual soundcard, but they lock you into a Dante format that requires Dante enabled hardware. 

Again, HZ at RC has his own audio over ethernet. I had taken a meeting with his peeps back a couple of years ago and we talked about VEPro. I told them that it just wasn't that stable for me. Sooner or later and it may take an hour it's going to pop or drop samples. Next I heard, HZ is using his own audio over ethernet software. Truth be told I don't know if he had been using it prior to that meeting, but I like to think in my mind that my conversation about VEPro with his tech team helped in some small way. 

Also, he's developed his own sampler software, which may be something I'm interested in when I put my own sample orchestra together.

Basically my hope is that in the future I can wean myself off of commercial products. I find that the companies, the people involved are far to unstable and limit through copy protection the use of their products and the functionality of their software. I have dreams someday of living of the commercial software and sample library grid so to speak.

I doubt that I will be able to do it all myself. At some point as I get more money I'll hire people, but as of now, all I got is me.


----------



## Gerhard Westphalen (Nov 3, 2014)

josejherring @ Mon Nov 03 said:


> Thanks for your input. Windows Touch screen or Linux for the touch controller. Linux rather than Windows for reasons I'll explain later on down this post.
> 
> I use VEPro but I find it limited in that it will only stream so much audio before it does a bunk. I figured it's because it has so many other functions as well, vst hosting, mixing ect... Audinate is just a straight up virtual soundcard, but they lock you into a Dante format that requires Dante enabled hardware.
> 
> ...



They're now using VEP at RCP. I've seen it in videos at Hans's studio and in an SOS interview of Junkie XL he talked about using it in his setup.

With the new Dante Via they claim that you don't need any Dante enabled hardware.


----------



## José Herring (Nov 3, 2014)

Whoa. Tell me about the Dante Via. I don't think I've heard of it. Checking now.


----------



## Jaap (Nov 3, 2014)

Hi José,

A while ago I stepped into the same direction and I have not read everything yet in this topic (have to go in a few minutes), but wanted to link a few good reading suggestions I got in that topic.
http://www.vi-control.net/forum/viewtopic.php?t=40100

I will try to post a bit more later today :D


----------



## marclawsonmusic (Nov 3, 2014)

Based on your goals, you definitely need some C++ in your arsenal. So, to answer your original question, yes, learn some C++.

However, I will say that some of this commercial software just needs time to mature. Something like VEPro will one day be staple software for studios, much like web browsers are today.

So, you might find that writing your own 'browser' is not a worthwhile effort.

Either way, I wish you success.


----------



## José Herring (Nov 3, 2014)

The funny thing about VEPro is that today I ran it all day heavy without even a hitch. Other days, I run it and it glitches 2 or 3 times an hour. 

If they are using it at RC now you have to keep in mind that they have 10gigabit routers there. I wonder if that would make a difference.


----------



## Gerhard Westphalen (Nov 3, 2014)

josejherring @ Mon Nov 03 said:


> The funny thing about VEPro is that today I ran it all day heavy without even a hitch. Other days, I run it and it glitches 2 or 3 times an hour.
> 
> If they are using it at RC now you have to keep in mind that they have 10gigabit routers there. I wonder if that would make a difference.



That wouldn't make a difference. In my system I have around 30 audio busses coming in from one of my slaves and it only uses a few megabytes. There are too many factors which can affect VEP's stability so you just have to optimize your system and network in order to improve the performance. 

How do you know that they are using 10 gigabit switches for their VEP networks with 10 gigabit NIC's? 

I doubt any program that a beginner could create would achieve anywhere near the stability of VEP. You'd need an expert programmer. 

FYI from Rctec "Our protocol is not better than VEP, it's just older. VEP wasn't around when Mark Wherry designed it for us."


----------



## José Herring (Nov 4, 2014)

I use to see tons of DELL Power connects around RC. I just assumed everybody was using them. Personally in the studio I was in we used standard 1gigbit. But we were rather broke compared to the other guys .

I'm not worried about it. VEPro works good enough for now. I could tune it further. But VEPro again doesn't really do all that I need. It's only a VST host. I'd like to buss audio out to a PT system as well, which VEPro won't do. And in the future buss audio out of the studio to a mix facility. 

Sorry, I just have these wild ideas really.


----------



## OLB (Nov 4, 2014)

I didn't have much programming experience (some html) and I was in the same boat as you a few months ago. Wanting an application that had articulations for cc's, faders etc. 

Max MSP is actually pretty good at this and you can export it as a standalone application. 

This is my personal application that I can modify to my own needs. It sends cc's or program changes in my case. Transport controls. OSC control. 
Every articulation (tile) can be triggered by a key on the keyboard.

https://dl.dropboxusercontent.com/u/2539838/ATP.png (Link)

You have to get your head around some things but once figured out it's good fun.


----------



## karmadharma (Nov 4, 2014)

josejherring @ Mon Nov 03 said:


> The next goal is to create a simple and lean no bloat audio over ethernet app kind of like audinate but with no need to use hardware.



as somebody that's been programming for a living for 15+ years (unfortunately for me music is just a hobby) and where most of those years have been spent in the network-related environment (although unfortunately not music related) you will soon find that 'simple and lean audio over ethernet' is a lot easier to say than to do.

If you are really interested in this my suggestions would be:

- learn python, so you can learn the concepts behind things without being tied down by all the minutiae in C++
- once you are comfortable with python learn C
- once you are comfortable with both write some sort of client/server app where the server is in C and the client is in python, you can get quite fancy about it, it would be the most useful (i.e. you can reuse this later to test things) to have actually the client and the server in C and python be a proxy in the middle where you can tune latency, packet loss and so on
- meditate a lot and develop tolerance for stress, because the moment you start doing anything realtime in a modern OS you will need to be able to cope when your code works just fine in your lab/environment and as soon as you move it to a customer environment the gremlins start having fun

C++ is not needed IMHO if you want to work in the networking stack, it can be useful for other things of course, but these days you can write in so many languages, scala, rust, C#, julia, ... the choice is mostly related to what toolkit you want to use (say Qt) and/or which platform you are working on.

In the end as somebody said above, programming is like physics, the physics is there, you can express it in all sorts of different idioms, as long as you know the concepts, so my suggestion is to start with a language that has the least encumbered syntax as possible, python, and then move to a language that's as close to the metal as meaningfully possible, C, so you also learn memory management and so on.

good luck!


----------



## JBZeon (Nov 4, 2014)

Gerhard Westphalen @ Tue Nov 04 said:


> I had the EXACT same thoughts this summer. I experimented with different audio over ethernet solutions but nothing worked well. Waiting for Dante Via to be released.
> For a touchscreen I just run Emulator Pro but I wanted to make my own program similar to what Mark Wherry did.
> I picked up a book for starting out with C++ but so far I'm nowhere near knowing anything remotely close to a touchscreen controller software or anything involving ethernet.



For touch screen control i definitely go to MAX....this is my custom touch screen developed in MAX 6, ok, you need some skill and understanding basic programing in MAX.

https://lh3.googleusercontent.com/-4vTYirFasrU/VFktv48LjJI/AAAAAAAAAQE/i7ko8JGrlg0/w1828-h1028-no/Custom%2BmaxCubase.jpg (Custom Cubase Max TS)

A problem with max is that there is not native support for multi touch, you need to implement it if you want multitouch gesture inside MAX.

C++ it's more complicated from start than MAX but if i were younger for sure will continue learning C++ but it requires total dedication and lately the days are shorter..... and shorter...


----------



## José Herring (Nov 4, 2014)

JBZeon, that's almost exactly what I'm looking for. Maybe a little less buttons but pretty spot on. Why did you need to know C++ to program this in Max? Seems like the purpose of an object oriented environment is that you don't have to know a programming language.


----------



## SergeD (Nov 4, 2014)

Maybe LiveCode could do the job, who knows...


----------



## JBZeon (Nov 4, 2014)

sorry, a typo.

No, you don't need C++ to program something like this in Max.


----------



## José Herring (Nov 4, 2014)

JBZeon @ Tue Nov 04 said:


> sorry, a typo.
> 
> No, you don't need C++ to program something like this in Max.



Thank God.


----------



## samphony (Nov 5, 2014)

Learn Swift and build new code software and surprise us 

https://developer.apple.com/swift/


----------



## Silh (Nov 5, 2014)

Agree that learning how to program is more important that the choice of language. How you manage your data, the algorithms you use, the concepts... all are rather independent of your choice of language. Each language will have its own quirks, and can make some things easier and some things harder...

Ultimately though, I think your choice of language will probably come down to your target platform and libraries and such you may wish to use (as mentioned above, using the VST SDK for example would incur certain limitations). Though admittedly once you get advanced enough, you can mix and match... but that isn't necessarily pretty or recommended for a first project...

I'd probably say that C++ would likely give you the most flexibility from being more low-level, but I'm not sure if I would recommend it as a first/learning language because you would have to deal with things such as memory management. Maybe as a second language though, before you get too spoiled by all the things that other languages do automatically for you


----------

