Rolling your own editor/librarian

[BluMunk]

This is a question for (I think) any software developers in the room.

 

I'm taking some computer science courses in order to develop some new skills. Maybe for work, and maybe just for fun. Regardless, once I get some level of comfort and ability, I'll want  to really dig into a project to continue learning/working outside of course assignments.

 

As a keyboard player, my mind went immediately to some kind of editor/librarian for one of the synths I've got. I am far far from ready yet, but I figure if it's a reasonable sort of project I can at least start thinking about scope/features now.  And, I can collect categories of knowledge I'll need to acquire to help me be successful.

Has anyone here built their own librarian for a synth? I'm assuming that at its core it involves some combination of MIDI/sysex communication between the computer and the synth? In my mind, this seems like it could be pretty straightforward. Am I right?

Anyway, I know this is a little off topic, but thoughts appreciated!

[Mills Dude]

I'm a professional software developer in the financial industry (helping traders get richer), mostly .NET/C# UI on 'windoze' (as referenced on the other thread) but also ramping up on web UI JavaScript, HTML.  I cut my teeth on C/C++ Unix (as we used to call it before in the days before Linux).

 

I'll be frank, taking a few CS courses won't really cut the mustard if you wanted to build a working editor/librarian.  What they teach in CS programs is more about basic data structures and algorithms.  What they don't teach much of is modern software engineering, the science of constructing usable programs.  That's typically left for you to pick up as you start your career as a programmer.  

 

Its kind of like someone who's taking piano lessons, but now want to be a keyboard player in a good band using synths and stuff.  A totally different skill set that may take a long time to develop i.e. learning to play be ear, learning about synths and sound editing, that sheet music is almost useless for this.  As we know, it can take years to transform from playing low level classical sheet music to being a keyboard guy. 

 

I don't want to dissuade you and it could be a great learning experience.  I can read all the theory I want, but unless I start writing code and applying those skills they don't develop.  But if you're pretty green to application development, it will be a daunting task and could take you a long time to develop something usable.

 

Let's leave the MIDI interface API side of this out for now.  Do you want to build a graphical UI or would your interface be command line only?  What's your target platform? Windows, Mac, Linux or do you want to try cross platform which is way more difficult.   

 

What framework would you be using to build your UI?   You have to know them and pick one and develop expert level skills in that framework.   Part of my job is to pick one of these and excel by reading a lot of documentation, blogs, etc.  Starting with a simple application and ramping up to something more complicated.  It can take years to master one of these frameworks, so I need to pick wisely as I've seen so many people pick something only to see it become obsolete. 

 

There are number of cross platform frameworks for UI development -- https://terminalroot.com/the-7-best-cpp-frameworks-for-creating-graphical-interfaces/ is a simple list I found on the internet.  Most of them are C++ based.  Qt is very popular for this purpose, I believe that Reason is based on QT although not sure. 

 

If you're targeting Windows (windoze) exclusively, .NET/C# with Windows Forms API is fairly accessible.  Windows Forms is an API layer for writing UI applications.  Its pretty old now, there are some newer ones like WPF or even Xamarin Forms which is supposed to be cross platform.  Win32 API has MIDI support and there are a bunch of Nuget (open source) packages available for .NET Midi.  Xamarin seems to have support for CoreMidi.  

 

This could be done using the new fangled Web technologies, where your UI would be run in the browser or made into a desktop application using something like electron.  But the browser can't interface with the MIDI library on the OS to the extent you'd want it to. Yeah, I believe you could play MIDI, but for an editor/librarian you need to actually manipulate the MIDI stream.  To do a Web UI effectively, you'd need to build a server application that would interface directly with the OS level MIDI interface.  So most of your logic would be on the 'server side' while the UI is just managing the check boxes, drop downs, button clicks, etc.  and sending those commands to the back end.  

 

On the web side, MS also has ASP.NET which is popular.  Its different that straight JavaScript as you primarily code in C# with some HTML.  Building off this MS also has Razor and Blazor frameworks which are capable of using WebAssembly to run more code client side, in the browser.  

 

Java UI is also possible.  I'm not that versant in that tech stack, I believe Java SWING is the choice there.  Some of the financial institutions still develop UIs using SWING.  My desktop Merill Lynch trading app is Java SWING and it's cross platform.  Not sure what MIDI capabilities exist in the Java Framework but can also use JNI (Java Native Interface) to call C code which can better interface with the OS.

 

I used to dabble with Borland Delphi (now supplied by Embarcadero).  It's language is Object Pascal but its a very nice environment although these days mostly obsolete.  No jobs out there for Delphi programmers.

 

The UI framework of choice would dictate which language you would code this in.  Then there's the task of learning how to be proficient in that language.  

 

Then there's the task of picking an IDE (Integrated development environment).  Each one the platform and UI frameworks would dictate that choice. 

• .NET - MS Visual Studio,
• Java - Eclipse, NetBeans or IntelliJ IDEA
• C++ -- Good luck, most people use Vim as an editor and command line for building but MS VSCode (Visual Studio Code) is becoming more popular for this.
• Web -- most everyone using VSCode these days.

Those old school freeware/shareware editor/librarians we used to use were almost exclusively written for Windows using either C++ using MFC/Borland library or Visual Basic.  If cross platform, either was entirely using a different coded application that looked like the other or using some special framework like Qt or wxWidgets (which Audacity uses).  But all the direct OS code to interface with the MIDI subsystem would need to be specific to the targeted OS.  In the C/C++ case of building a monolithic application, it would involve using #ifdef WIN32  all over the place.

 

If you were trying to develop skills for the job market, learning the Web stack is the most marketable these days.  Building this in Web Stack would be most complicated but you'd develop really marketable skills.  Wrapping your head around the application being split into 2 parts, client and server, might take a bit as we typically think about monolithic programs.  I've got a Behringer XR-18, the UI is like this.  It can run in the browser and communicates with the server running in the unit.  Every setting change sends some command (via a websocket or REST) down to the server.  Server sends asynchronous messages back to the UI, for the level meters and general status, etc (typically via a websocket or SSE).

 

To do this effectively, I'd say these steps are necessary

1. Pick a target platform/OS  -- MacOS or Windows, sure you can try Linux also.
2. Pick and learn how to use an IDE.
3. If you want to build a UI, choose a UI framework and learn how to use it by building simple applications.
4. Learn the MIDI API for the target OS.  Also need to know about Hexadecimal number system and bit shifting.
5. Learn how to code/build/debug repetitively.   The software engineering aspect, all the while learning how to write good code which is an art unto itself.

Not sure where your skill sets fall, but even if I were to start something, we'd be talking at least a few months to get something very basic working.  Again, I don't want to dissuade you, but if the goal is for hobby purposes, its a long road ahead.  If you're looking to pick up marketable skills to transition to a career in programming, still a long road ahead but there may be more incentive.

[DrEsophagus]

You're right. I took comp sci in school and learned mostly on Java....which I've used all of zero in my job, I mostly use SQL and VB/C#. I couldn't even begin to figure out anything that managed a synth library or MIDI to be honest.

[BluMunk]

@Mills Dude, thanks for taking the time to write that imminently valuable response!

Point totally taken and understood about the size of the project I'm being kind of hand-wavey about. I'm really expecting that this is going to be big, and something that takes a long time, even after I've acquired some of the skills I'd need to be successful.

 

I work for a software company (medical records and billing) in a development-adjacent capacity. I'm going into this feeling comfortable with reading code and code syntax (up to a point, of course), and with a surface-level understanding of most of the choices you've laid out.

As you say "I can read all the theory I want, but unless I start writing code and applying those skills they don't develop." So, I figure at some point I'll want to try to apply these skills to <i>something</i>. I asked myself "what's some software I don't have that might be useful to me?", and this was a clear idea.

For sure, while I'm taking about an "editor/librarian", I expect that the first story I work on will be something super "simple", like: send hard coded cc values over MIDI. Maybe that story takes me a ton of effort.  That's ok.

I might have come across a little wishy-washy in my OP, but to be honest the real inspiration here is to open up some new doors professionally (unless it turns out I hate coding). I'm not blind to the gap between "took some classes" and "is ready to get a job as a developer".  I was recently involved in the hiring process for a team I'm on, and we interviewed a number of folks who had recently completed software boot camps. They all had identical resumes, mostly identical projects in their portfolios, and didn't demonstrate much depth/proficiency outside of the things they'd done as assignments. I'm maybe getting a little ahead of myself with this project idea, but it's clear that no matter how many courses I take, projects I undertake on my own are going to be key to my development (no pun intended), and to demonstrating I can actually accomplish work outside of the context of a class.

Anyway, to answer some of your questions:

GUI vs. command line? Definitely a GUI. I am old school and enjoy the command line as much as the next person, but this isn't going to feel usable without a GUI.

Target platform? Probably Windows. I work on both Mac and Windows machines, so it feels like a toss-up for me.

Framework? No idea or how to choose. A big chunk of our codebase at work is built on Qt. So I suppose I might have some friends/colleagues who could give me advice if that's what I used.  If I was ultimately looking for a job at my current employer, I'd be looking at Qt/C++, Ruby on Rails, PHP (or I could support our legacy products with perl and python).

IDE? The class I'm in right now is using VSCode. Seems fine to me, but I have no idea.

I'm still a ways out from actually diving into this for real, but I appreciate you helping me understand what questions I need to be asking/steps I need to be figuring out.

 

 

 

[Mills Dude]

Thanks for clarifying, I have a better idea of what you're working with. 

 

For modern software development, I'd say PHP and Ruby on Rails is considered obsolete these days.  Sure, I get a lot of places still doing this and maybe the medical records company you work for primarily does this.  If I wanted to become a modern software developer with marketable skills, I'd skip those stacks. 

 

Pretty sure that doing MIDI with PHP would be nearly impossible as its an environment meant for serving web pages.  Looks like there's some stuff for Ruby -- Ruby Toolbox.   For me, I wouldn't waste my time on the Ruby front, but you know that business space better and if there's a market for Ruby developers out there, then give it a go.

 

Python on the other hand is not considered legacy in the industry, perl yes, python no.  Python is the teaching language of choice these days, so lots of devs coming out of school with python and quite a bit of jobs available in this space.  In the financial industry, the quants (Quantitative Analysts) who come out with high level math degrees (MS Math or Statistics or in some cases Financial Engineering degrees) all code their algorithmic trading in Python.  In general, having good Python is marketable, Ruby not so much at least as I see it.

 

On the code camp topic, I'm aware of them and I've even presented at code camps.  I'm pro code camp as I feel there's a big difference in being an Computer Scientist and actually being able to write good code.  A code camp won't guarantee you write good code, but its geared toward teaching the applicable skills.  I often joke with my co-workers and some may get offended when I say "We are not Computer Scientists, we are the plumbers of the 21st century".  My point being that learning structured automata, language theory and compiler design are skills not really applicable to cranking out line of business applications.

 

In the financial industry now, there is a bit of push back on the code camps and many of the big banks are making candidates do LeetCode and HackerRank problems like "write an algorithm to find the longest palindrome in a string".  I've heard this is being done directly to try and weed out code camp graduates with they rationale that they lack theory or 'good problem solving' skills.  I personally disagree with that assessment and would much rather hire someone who can write clean, maintainable code that works well and knows the target frameworks/OS we're building on.  I don't want coders who waste time writing their own hash tables, when that problem has been solved a long time ago and we have libraries written with implementations written by much better programmers than us (i.e. the computer scientists).  Google, MS and other big tech companies for sure are doing CS, but for the rest of us, yeah we're just plumbers.  I'm not knocking plumbers, they have to solve important problems every day but they're doing it within a set of guidelines and frameworks.  

 

So back to the topic at hand.  If you have some exposure to Qt/C++ you can certainly start from there.  While C++ is still very marketable, what I find though is that the jobs are available for real C++ gurus.  Modern C++ can be quite daunting, with the concept of templates and those shops hiring would probably expect your skills to go further than just being able to write some simple C++ code.  Even the old C style where everything is pointer based can take a while to master.  Modern C++ requires knowing about copy constructors, references, l-value references, etc.  Everyday coding is C++ is much less forgiving than other environments.  Just figuring out syntax errors from your compile step when trying to use template classes from the standard C++ library can be frustrating.  A missed semicolon in the wrong context could trigger a confusing error that when you finally find it and its just a simple syntax error can be frustrating.   Not to say that you can't use Qt/C++ to jump in and write simple C++ code to get something working.

 

I could be way off base here as I'm skewed to a more competitive job market.  Could be that the space you are familiar with, those C++ programmers are not at the level I'm thinking about.  

 

I like the Python idea.  There is a Qt wrapper for python - PyQt and looks like there are some python libraries for MIDI   A good skill to develop is understanding OO (Object Oriented) programming.  In general, it's just easier to get started in something like Python than jumping into the C++ stack.   VSCode is fully capable as a python IDE.  

 

Ultimately all the languages boil down to how to break a problem down into small steps, by decision trees (if/else/switch), generating and iterating through sequences (loops) and breaking steps into smaller manageable units (source files, classes, functions) to maximize reuse.  So learning how to do these things is the key.  Starting with something like Python is just easier to get your feet wet. 

 

Strongly typed vs. dynamic languages is also a consideration.  Python is considered a dynamic language with a weak typing system.  C++/C#/Java are strongly typed languages, meant to catch errors at compile time but you need to consider understanding the underlying type system.  

 

Modern full stack development, i.e. web development, is the where the market is hot and will be hot for a long time.  Web based UI using React/Angular/Vue (in that order) against a Node.js backend.  All written in JavaScript or TypeScript which is a more type-safe superset of JavaScript.  The backend can also be Python, I see this a lot as well as Java/C# backends.  C# is gaining a bit of traction due to .NET becoming cross platform.  

 

The older web stack is pure HTML/JS using jQuery on the browser and some backend, what we call LAMP style.  I'm sure there are lots of jobs still there but in my circles those guys are considered the Cobol programmers of the 21st century.  But don't knock Cobol, still people making money doing that.

 

But for a developing a standalone, old-fashioned MIDI editor librarian to get your feet wet, I'd use Qt either with C/C++ or Python just to get yourself familiar with basic programming.  Since you work with Qt devs, you can get some guidance there.  I'm not familiar with Qt style.

 

If I were doing it and someone paid me to crank out an app for Windows, I'd probably use C#/.NET as I'd be fastest to market in this stack.  If I wanted to expand my skills and take more time, I'd do a React frontend with some cross platform backend that could do the MIDI stuff directly with the OS.  The backend and frontend can run on the same machine.  Then package it up with electron as a standalone application and play a bit with docker and run the backend in a docker instance and use some sort of lite NoSql Db for data storage.  As these are the tech stacks I'm in the process of trying to master.  

 

One thing "I" would worry about with Qt, is how can the UI be broken up into separate components.  Thinking about a full featured editor, there may be literally hundreds of widgets on the screen.  Throwing these all into one 'Form' class would be pretty daunting and manageability would be an issue.  We think better in smaller packets of work instead of dealing with a source file that's thousands of lines long.  I see it all the time, people cranking out spaghetti code in multi-thousand long line classes and source files.  Its a maintenance nightmare and prone to bugs. 

 

So how to break things up into smaller 'components' that can be brought together on a single screen or page.  The modern web frameworks React/Angular/Vue are all about breaking down the application into smaller 'bite-size' components.  Not sure how you do this in Qt.  Also possible in the C# WinForms space, but you need to plan ahead on doing it the right way.   That all comes down to the 'software engineering' aspect.  How to write clean, maintainable code and perhaps using a unit test framework to develop those skills and habits.  

 

To get more theoretical on this, function pre and post conditions should be well known and the parameters to a function should be well thought out,  Thinking in terms of class member functions, if a function touches or modifies internal state of the class, it should be deterministic.  A common problem I see is long member functions that try and do too much and touch a lot of internal state variables.  Good OO programming is about encapsulation and data hiding with well established operations that may modify internal state.  On the contrary, I see a lot of sloppy programming that modifies so much internal state in a single operations (i.e. functions) it becomes hard to track down bugs.  Writing small functions, that do one thing and do it well and are properly tested is a discipline that leads to more manageable code.  But this is not really taught in CS programs or Code Camps.  Its learned though experience and by applying certain principles in the way problems are approached.  Much different than cranking out a function that can find the longest palindrome in a string in O(N*logN) time.  Composing a large scale application from a smaller set of components and classes yields better results with increased maintainability and reduced bugs.  I'm a big proponent of SOLID, especially the S part.  Don't stress to try and understand these things from the get-go just try to keep your code simple.  I try to break down any function that's longer than 30 lines or so, into a simpler set of steps. 

 

Yeah, I'm getting into the weeds, but I am passionate about it and I can be bit prolific and a bit of a nut.

 

Anyway, good luck, happy to continue along this thread or for others to pipe in with suggestions and I'll try to not go off on tangents.  If you start something, get it up on github and we can follow along and give some suggestions.
 

tl;dr -- Move forward with Qt since you've got some potential help available.  I'd look at Python instead of C++ since its a better beginner language and more approachable.  If you're looking to develop high paying, marketable skills, modern full-stack development is where its at.  But to get your feet wet, I think Python is the best approach.  Try to develop good coding skills from the start with small, maintainable classes and components and 'compose' a larger application by 'gluing' these components/classes together.

[stoken6]

Fascinating thread.

 

Cheers, Mike.

[marczellm]

I believe even though the real time controllable parameters of the current sound might be documented in the MIDI implementation chart of the instrument, the commands to read out / write back a sound / a bunch of sounds might be undocumented (if they even exist, given that there's no official librarian). This might render your project impossible, or maybe you're in for some nasty trial and error based reverse engineering.

[Theo Verelst]

Back in 1987

[Adam Burgess]

Try getting in touch with the guy who wrote this http://pcgtools.mkspace.nl/
He's always updating it and works brilliantly. Don't know why Korg doesn't employ him. 

 

Much better than the clunky SoundQuest stuff that is still stuck in the 80s. He's definitely passionate about it and sure he'd give you some insight into his workflow and methods if you're serious.

I'm currently doing a bit programming of my Roland Integra-7 over DIN MIDI. Literally everything has a SysEx command.

RX/TX-ing simple serial strings is pretty easy to get your head around. Making it look good and putting buttons in the right place is a talent in itself.

I always wanted to learn to code properly - think that was supposed to be my actual career, but ended up gigging a lot when I got to 9yrs old and forgot to get a real job 🙂Good luck on the future, man. 

Thank you, too @Mills Dudefor a very interesting read 🙂 

[Theo Verelst]

For engineering, and to a lesser extend for sw engineering, methodology can be everywhere on a line from hard technical approach to elusive theory and style having no real connection with technical givens or the desires of the use.

 

When making a piece of Midi software on for instance a PC, what should the user interface look lake? Ik you ask the bean counters, you'll get a whole different set of desires then if you ask a musician, most likely. A leader in sw might also have a completely difference software agenda in mind compared with an average IT guy.

 

From what I read in the original question I'd say a practical method could be to somehow encapsulate the necessary Midi communication (essentially a read and a write command, depending on which windows devenv  you want (ming/gnu use to be good) two library functions) in a compact program or loadable library and use a handy script language (like Tcl/Tk) to make a rudimentary interface.

 

T

[AROIOS]

12 hours ago, Mills Dude said:

...
Python is considered a dynamic language with a weak typing system.  C++/C#/Java are strongly typed languages, meant to catch errors at compile time but you need to consider understanding the underlying type system.
...

Small nit here, Python is strong typed.

Not that it's critical to OP's potential project, and it certainly doesn't take away from the excellent advice shared by Mills Dude.

[Stokely]

I'm more of a scripter, not a programmer, but I came to appreciate strongly-typed languages after I got super lazy with PHP and created tons of headaches for myself.  Hell you didn't have to even declare variables before using them at the time at least...such bad practices I used...

As an aside about librarians--I wish every company would release one for their products.  I really, really appreciate the Novation librarian I use with my Summit--it makes it so easy to assemble banks and try out sounds.   By way of comparison, my buddy had nothing similar he could use with his Prophet Rev 2.
 

It's pretty irritating that Yamaha doesn't include the Melas tools for my Modx.  

Editors I would think are another level of complexity from librarians.  Obviously some synths like the two I mentioned above don't really need an editor, being knobby and all!  

[jazzpiano88]

When learning applying a new/unfamiliar language to a problem (e.g. implementing a editor/librarian), I always broke the problem into pieces. I'd demonstrate my ability to execute each piece and then design the overall capability and look/feel.

 

Example for editor/librarian:

Write a hello world program that reads a setting from your synth.

Write a hello world program that writes a setting to your synth.

Write some test programs that generate the UI controls you will need, and read and write to these UI elements.

Write some test programs to manage the full set of synth controls so you can save and call up settings for the library.

 

Once you've mastered the individual pieces, you can put them all together in a fully functional program.   You'll learn a lot along the way, scrapping ideas that won't fit your design paradigm and redoing lots of code, but that's what gives you experience.  I've done this as an engineer countless times over the years beginning with C and Windows API and ending up with Python today for machine learning and AI applications.

[Brad Kaenel]

Mills' responses are en pointe.

 

I've spent 45 years in the Microsoft development ecosystem, so the only tools I can speak to (these days) are Windows, .Net and Visual Studio. 

 

The only thing I would add (or reiterate) is to not bother with the intricacies of writing the raw MIDI (serial communications) code yourself.  There are good libraries of MIDI functions that you can purchase or acquire open-source (example: https://github.com/melanchall/drywetmidi) and simply call those from your code.  Your task would then be reduced in scope: principally to managing the file I/O of creating, naming, storing, recalling, and transmitting streams of MIDI commands.  That's still good yeoman work, yet simple enough that you will probably be able to more successfully manage it in your first go-round, rather than jumping down the rabbit hole into the myriad details of the MIDI protocol, right out of the gate.  You won't need a slick UI to do that.  You could even start by just writing some simple command-line tools, to get familiar with the MIDI library you choose.

[Theo Verelst]

Interesting lib, shame it is limited to .net .

 

Nowadays the constraints for building a patch editor or librarian are different: even USB Midi is ridiculously slow compared to even 1 thread processors' compute power, one PC can probably load all the world's synthesizer sound banks (minus sample based) simultaneously in main memory.

 

T

[bfields]

I"m sure everything Mills Dude says is right, but I'd personally not worry that much about making all the right choices the first time--just dive in, take the quickest route you can to reading/writing some MIDI data, and see what you can make work.

 

There's a feeling of joy the first time you run your program and it makes something happen.  Aim for that and don't worry about making some mistakes.

 

Maybe eventually you'll build it up into something useful at least to you, maybe not, either way you can have some fun and learn a few things along the way.

[Mills Dude]

3 hours ago, bfields said:

I"m sure everything Mills Dude says is right, but I'd personally not worry that much about making all the right choices the first time--just dive in, take the quickest route you can to reading/writing some MIDI data, and see what you can make work.

 

There's a feeling of joy the first time you run your program and it makes something happen.  Aim for that and don't worry about making some mistakes.

 

Maybe eventually you'll build it up into something useful at least to you, maybe not, either way you can have some fun and learn a few things along the way.

Totally agree, you can only learn by doing and many times we learn best from our mistakes.  Sometimes I paralyze myself into trying to get it right the first time.  Then I have to smack myself and just get some code on the screen and refine it as I go along.  Sure there a some geniuses like Mozart who could just write symphonies out of his head.  But the rest of us need to scratch and claw our way to get something cohesive.  

 

I tell the young'uns, ABC - Always be coding.

 

In the industry there is a formalized principle of doing code reviews where the team reviews the code you've written.  Unfortunately, I've seen this go wrong where the reviewers are overly critical and it can hurt the person being reviewed.   I hate when this happens, these reviews should be to help not just the person being reviewed but to help the whole team get better. 

[Theo Verelst]

When I had just graduated (30 y ago) and needed a job besides some gigs I did my first full time job at university was in software and (software-) language design and OO methods, I recall designing a 3D graphics design language and sort of interpreter. It had to be useful, as in the application to a practical project had to have merits and my professor, who had a strong computer languages background, had to find it interesting.

 

That's a different situation from doing a software assignment for passing a course. Someone paying money for a product is also different motivation: in that time I had written a complex librarian for DX7 sounds with for the time a big database, and it somewhat sold, had a good review in a magazine, which I suppose made e proud but as a project it wasn't extremely profitable.

 

T

 

[jazzpiano88]

19 hours ago, Theo Verelst said:

Interesting lib, shame it is limited to .net .

...

T

 

Several MIDI libraries are available for Python as well.  Could probably have something rudimentary working in a day using one of these with Pycharm CE.

https://www.jetbrains.com/pycharm/download/#section=mac

https://mido.readthedocs.io/en/latest/

 

[jazzpiano88]

10 hours ago, bfields said:

I"m sure everything Mills Dude says is right, but I'd personally not worry that much about making all the right choices the first time--just dive in, take the quickest route you can to reading/writing some MIDI data, and see what you can make work.

 

There's a feeling of joy the first time you run your program and it makes something happen.  Aim for that and don't worry about making some mistakes.

 

Maybe eventually you'll build it up into something useful at least to you, maybe not, either way you can have some fun and learn a few things along the way.

 

Exactly my suggested approach as well.  Incremental approach is very satisfying and confidence building.

[Reezekeys]

Editor/librarians for hardware synths are a long-gone market, no? Anyone remember MOTU's Unisyn? That being said, making this a programming challenge is great and I wish you luck. Way back I was a hobbyist-level programmer with my Atari ST (yea, I said WAY back!) and programmed an editor/librarian for my Akai S900, strictly for fun and a learning experience. I never released it into the wild. I also did some librarian & patch management apps for my Korg M3R and even wrote a program that turned an Epson 9-pin "high rez" bit-map spooler dump from a Dr T's "Copyist" notation file into a graphics file I could edit. It was fun - but the Atari ST's built-in midi ports (with OS-level calls) and GFA Basic having a compiler that turned code into standalone apps made it pretty easy. Those were the days.

 

I don't know how hardware synths communicate v.a.v. editing their internal parameters these days but when I was doing it it was strictly sysex (F0....F7) and usually involved checksums and sometimes handshaking. Roland had the best documentation of any synths I saw, with detailed "parameter maps" that specified the offsets to each parameter and let you request or transfer data to and from those locations. If I could decipher this stuff then I assume any beginning programmer could! The key for me (and I assume anyone else doing this) is good documentation from the manufacturer.

[ElmerJFudd]

Side note. 
 

For Cubase users - they have some features built in that may hit on some of what you want to do as far as customized control of hardware midi instruments in your setup goes.  
 

Midi Mixer Maps

 

https://www.soundonsound.com/techniques/creating-cubase-midi-mixer-map-yamaha-sy85-part-1?amp

 

https://www.soundonsound.com/techniques/creating-cubase-midi-mixer-map-yamaha-sy85-part-2?amp

 

And Studio Panels 

 

https://www.soundonsound.com/techniques/creating-cubase-device-panels?amp

 

[jazzpiano88]

14 hours ago, Reezekeys said:

I don't know how hardware synths communicate v.a.v. editing their internal parameters these days but when I was doing it it was strictly sysex (F0....F7) and usually involved checksums and sometimes handshaking. Roland had the best documentation of any synths I saw, with detailed "parameter maps" that specified the offsets to each parameter and let you request or transfer data to and from those locations. If I could decipher this stuff then I assume any beginning programmer could! The key for me (and I assume anyone else doing this) is good documentation from the manufacturer.

 

Me neither.   However, one evening I brought my powered-up TX7 into the near field of my Montage 88 and the TX7 started to glow, vibrate, and then completely disappeared from my hands.   I haven't seen it to this day.   

[Theo Verelst]

My librarian could search for "lookalike" sounds, which would be a list of patches of which the parameters where to some numerical extend close enough to a selectd one.

 

T

[Lady Gaia]

Late to the thread, but I thought I'd toss in my few cents.

 

Is making a librarian with a decent user interface a substantial undertaking?  Absolutely.  Writing any complete application requires a sizable collection of skills that don't come overnight.  Does that mean you shouldn't work with that as your goal?  Absolutely not.

 

Having an objective and learning along the way with small wins is an incredibly valuable experience.  Your project could start out as a simple command-line tool that dumps information it gets from querying your synth.  That removes a lot of the complexity, and lets you build up a library of useful code that could eventually become part of a graphical interface.  Take it a step at a time and you'll accomplish things you never thought you'd be up for.

 

As for available frameworks?  I'm just not a fan of Qt.  Every time I get a commercial app built with Qt it is painfully obvious and frankly C/C++ are not particularly forgiving languages.  There's simply no great way to abstract over something as inherently different as Windows and macOS.  Electron takes a slightly different approach by being its own thing - basically a web browser with native trimming where it matters most - and having some experience with a variety of web technologies can come in very handy commercially.  Electron is what I used for PXToolkit, opting for TypeScript instead of raw JavaScript for sanity's sake.  I'm not sure what @Mills Dudeis referring to regarding limited MIDI access.  I'm not doing anything fancy but I have access to the raw MIDI stream and do sysex dumps without any problems.  All that said?  Writing for a single target platform is generally a lot easier than writing a portable UI.

 

As for languages?  Python is not a bad choice if you're just prototyping or building command-line tools, but it won't help you learn to build a decent modern user interface.  For real apps, C# is much more forgiving than C/C++ but it's largely Windows-centric.  TypeScript is JavaScript without its worst tendencies, and is largely portable within a web-like context like Electron.  Swift is fantastic for macOS / iOS.  Hard to go wrong with any of these, so long as you know what you're getting into.

 

Background: I was a software professional for many decades before retiring from a career that included leadership roles at Microsoft, Apple, and Amazon.  These days I keep my hand in as a hobby.  My PlugInfo utility (Swift on macOS) hit #39 on the "All Paid Apps" chart on the Mac App Store today, which I think is wonderfully absurd given how niche a product it is – and that you can download it for free if you don't feel like paying for it.

[jarrell]

Also late to the thread 🙂 I agree with Lady Gaia that Qt is not the way to go; I think cross platform frameworks in general are not what I would go with. You spend your time  learning their framework instead of the actual platform specific API's and design methodology. I would just pick one platform, and use either C++, or C# on Windows or Swift on Mac. Agree also that first developing it as a command line interface is a good way to approach it - a full feature Editor/Librarian requires a  non trivial UI, so maybe one step at a time.

 

In a previous lifetime I was a software engineer at Opcode Systems, and for a while was on the Galaxy team. Galaxy was our universal editor/librarian - it was an app that used essentially plugins for instrument specific editor and librarian features. It was a lot of code, and complicated - when you think about how to visually represent every editable aspect of a synth, or how dragging a multi to another position or bank window involves dragging their child patches as well, etc. things can get complicated. So I would start simple - command line send and receive of each type of patch (patches, multis, system, etc.), then proceed to entire patch banks - each step carefully verifying data. When you get all that working, you can then think about the UI. And, have fun with it!

[TJ Cornish]

I’m an IT professional, not a programmer, so I won’t give programming advice, however just wanted to point out that there are two different approaches to a librarian - online access via MIDI that requires hardware interface and protocol work, and offline file manipulation - taking a backup file, decoding it and rearranging the pieces.

 

I have no idea which would be harder, but they seem like pretty different approaches, and one may turn out to be a lot less work, depending on how far you go.

 

My selfish desire - PCG Tools for Kronos is great. There isn’t anything like that for the Roland Fantom, and I sure wish there were. I would pay $$ for that, even if all it did was rearrange scene slots and naming.

[BluMunk]

I don't have anything to add at this point, but I just want to continue the thanks to everyone who's participated so far. Obviously, I have miles to go before I get really started on this, even in an incremental way, but all the discussion has been helpful and inspirational context.

 

18 hours ago, Lady Gaia said:

Having an objective and learning along the way with small wins is an incredibly valuable experience.  Your project could start out as a simple command-line tool that dumps information it gets from querying your synth.  That removes a lot of the complexity, and lets you build up a library of useful code that could eventually become part of a graphical interface.  Take it a step at a time and you'll accomplish things you never thought you'd be up for.

This is exactly the point. I'm dreaming/talking big right now, but I do realize that from a practical standpoint, what I'm looking at is creating one small program at a time that centers around a theme. When I get to the point where I am asking "what do I learn next?", I need a "why?" to keep me focused.

Anyway, I don't have much more to add at this point, but I do plan on coming back to this thread for updates. Oh, and if anyone's curious, this is the CS course I'm starting with.

[elif]

I'd suggest not worrying about picking the right language and build environment at this point, because as your skills and the project complexity develop, you will be rewriting it anyway.  Take a look at PySimpleGUI.  The PySimpleGUI Cookbook has many examples. It might be what you need at this point and could get you quickly started on Python and Python GUI development.

[Baggypants]

It's not a librarian but I hacked on someone elses midi keyboard configuration tool using python and tkinter for the gui.

 

https://github.com/Baggypants/alesisvsysex