How To Create A Simple Plugin Host?

[very angry mobster]

If I could copy and paste parts of source code into a proto daw that would be awesome. I would just have to learn the code to tweak almost finished parts into how I want it to behave.

That would be awesome but it doesn't really work like that. As soon as you start writing code (c++ or the like) you're working at a pretty low level. The piano roll code you want to copy and paste will have many dependencies on the code around it. You can't start using the piano roll code in your new application without first either bringing it's dependencies over or replacing them with your own. Imagine trying to copy and paste a bathroom from another house into your own. All the plumbing connections to the outside world will be in a different position. No problem if you a plumber and can reroute those pipes easily but very difficult for the rest of us.

List of Open Source DAWs, Sequencers, and Hosts for Windows

IMHO if you goal is to write music, don't start writing code to build yourself a host or sequencer. You'll be writing code for years before you have anything useful. If your goal is to write music software, jump in. Coding is fun!

Have you considered something like note~ for max?

[swatwork]

If I could copy and paste parts of source code into a proto daw that would be awesome

I think you're seriously underestimating the work necessary to build a DAW, even a simple one. You aren't going to find the parts for a piano roll, mixer, audio engine, VST hosting, etc, 'lying around' on the net waiting for you to just cut and paste into the 'DAW of your dreams'.

If you really want to give it a go try looking at existing open-source applications such as QTractor, Traverso, pyDAW. Try googling for these or just 'open-source DAW' and see what you can find.

[Ivan_C]

There is a simple host application in the JUCE examples projects too

[JCJR]

A midi only sequencer would be "relatively simple". I speak of traditional hardware midi I/O, or possibly also writing the sequencer to be able to send/receive midi to other programs with some kind of interapp communication.

Similarly, an audio-only sequencer would be "relatively simple". Starting with single track play/record/edit, then expanding into multi track and vst hosting.

You can simplify by limiting yourself to no multiplatform ambitions. Pick winders or mac or linux and concentrate all efforts on the single target.

Also you can simplify by abandoning ambitions of multi-driver support. On winders, either pick asio or wdm or whatever, and don't try to make the program "equally friendly" to numerous driver models.

I'm not familiar with the vast number of current sequencers, but among the old dogs, some began as midi-only and crude, then became more refined over the years, and eventually shoe-horned in audio support.

Some began as audio only, progressed from crude to more refined, and eventually shoe-horned in midi support.

Then some such as finale, were concerned with notation, and midi-audio support was both shoe-horned in on top of the notation.

When you start out with achievable first goals, you end up after awhile with a zillion lines of code that has painted yourself into certain corners, and then the code turns into progressively more gordian knot of spaghetti as you shoe-horn in new features incompatible with current code, and too much old code to economically re-write within one lifetime.

A wise software architect would uderstand everything about midi and notation and audio and plugins before making the first design or writing the first line of code, thereby avoiding all the half-fast coding that were the initial baby steps. Maybe there are smart people out there who could do that right out of the starting gate. It would certainly be more possible today than 30 years ago.

The problem is that at some point you have to get your hands dirty in order to bring realism to the castles in the sky built in your imagination. One of the first things I did on mac toasters was write and sell midi driver support code, but it was hard to imagine what the ideal midi driver support would be after awhile, so I took a month to write a first midi only sequencer. Then took a year to write a second better midi only sequeancer. And so it goes.

[ghettosynth]

A midi only sequencer would be "relatively simple". I speak of traditional hardware midi I/O, or possibly also writing the sequencer to be able to send/receive midi to other programs with some kind of interapp communication.

Similarly, an audio-only sequencer would be "relatively simple". Starting with single track play/record/edit, then expanding into multi track and vst hosting.

You can simplify by limiting yourself to no multiplatform ambitions. Pick winders or mac or linux and concentrate all efforts on the single target.

Also you can simplify by abandoning ambitions of multi-driver support. On winders, either pick asio or wdm or whatever, and don't try to make the program "equally friendly" to numerous driver models.

I'm not familiar with the vast number of current sequencers, but among the old dogs, some began as midi-only and crude, then became more refined over the years, and eventually shoe-horned in audio support.

Some began as audio only, progressed from crude to more refined, and eventually shoe-horned in midi support.

Then some such as finale, were concerned with notation, and midi-audio support was both shoe-horned in on top of the notation.

When you start out with achievable first goals, you end up after awhile with a zillion lines of code that has painted yourself into certain corners, and then the code turns into progressively more gordian knot of spaghetti as you shoe-horn in new features incompatible with current code, and too much old code to economically re-write within one lifetime.

A wise software architect would uderstand everything about midi and notation and audio and plugins before making the first design or writing the first line of code, thereby avoiding all the half-fast coding that were the initial baby steps. Maybe there are smart people out there who could do that right out of the starting gate. It would certainly be more possible today than 30 years ago.

The problem is that at some point you have to get your hands dirty in order to bring realism to the castles in the sky built in your imagination. One of the first things I did on mac toasters was write and sell midi driver support code, but it was hard to imagine what the ideal midi driver support would be after awhile, so I took a month to write a first midi only sequencer. Then took a year to write a second better midi only sequeancer. And so it goes.

This is a good post, so, now go back and consider the things that I talked about. You can create midi sequencers in MAX and it already has VST support. Chuck, on the other hand takes a different approach and gives you a simple environment that allows you to start playing with music as simple data structures immediately.

Both of these tools, and some others, will allow you to start to understand some pieces of the puzzle without having to write "real" code at first.

In fact, Pd (pure data), the open source variant of max, also supports VST plugins. You should be able to knock up a simple pattern based drum sequencer in a weekend, assuming not much learning curve, a poor assumption, of course.

Download it and play with it. If you want to see code to do specific things, look for "externals" that do those things.

http://puredata.info/

[Zaphod (giancarlo)]

There is a simple host application in the JUCE examples projects too

but it is really far from orion. And working/extending it requires a lot of knowledge (ie c++)
I think "max" was a good suggestion. Anyway, I think this is the wrong approach, because it does easily amazing things, but it is really hostile if you miss something (I remember a friend with issues for a simple fft window not supported natively). It is like asking for a kit for building nuclear rockets: you should start from a little drone before. I think it is not clear the amount of complexity and work hidden inside orion. I would start from a simple fx plug-in, for example. Just my idea, after 10 years programming plugs; mabe someone more experienced in this subject could be more helpful

[DougCox]

You could look at the C code for my free Windows MIDI sequencer, PianoRollComposer, at
http://jdmcox.com

[avasopht]

A little inspiration for you.

My best friend got his first PC aged 13, learnt QBasic then eventually got a C++ compiler (probably when he was 14). This was back in 1998 when the Internet was a very different place, and suffice to say what I am about to tell you that he achieved, he did so without ever reading books on the subject.

So, by 16 he had worked out the following:
1: That video games use scripts, which operate inside of a virtual machine (he didn't use that term, he just described the abstraction). he figured this out by thinking about how a game like Zelda (SNES) would be made, as well as the animation sequences for Metal Gear (NES)
2: He had built said virtual machines in assembly langauge (he also wrote a basic VM in Javascript for his website that was teaching people how to write assembly code)
3: He had built a basic sequencer (very basic sequencer, namely for sequencing animations and sounds for the Nintendo Gameboy, but being a sequencer it could sequence anything, and was more of an event management system that strangely doubled up, perhaps in ideology if anything, as a management system for game states because of how it was designed)
4: He had written systems code that was so much faster than Nintendo's that the team, then, working on the Gameboy version of Harry Potter used my version in their code

Now if you asked most people how to go about doing that, they'd say, "YOU CAN'T", but any person with clear GOALS! will be able to achieve far more than the most talented genius! Get that book or the audio and don't let anything get in your way.

Now there is a lot for you to learn. Forget the curriculum. According to Albert Einstein, you will be come an expert in any field after just 90 hours of reading (typically spread out over a year in 15-minute daily chunks). If for whatever reason you wanted to cram those 90 minutes into a week's sitting, I would advise you to take regular breaks and regular naps (or deep meditation).

One little caveat. Repetition, repetition, repetition. The more you code the more it becomes second nature, as with anything, including thought processes such as planning and designing tests first.

Code Complete (get the second edition) has a fantastic list of book recommendations, as well as being a great book to read in its own right.

So there you have it. Everything you need:
1: Inspiration (my friend's story)
2: Instruction / direction (books)
3: Ambition (your own)

Take care.