Contributing to Zynthian Development

We would appreciate you to use the tools we use for developing, as it's a lot easier for coordinating the tasks, having traceability, testing, merging changes and of course, attributing the merit of every fix or improvement.

We use git as versioning tool and github as repository server and issue/task tracker: Zynthian's Repository Index

If you are a punctual contributor, you should follow this procedure:

• fork the repository
• make the changes
• test it
• make a pull request

When you are a habitual contributor, you will receive write access to the repositories you master and would use development branches instead of forking/pull-requesting.

Also, it's a good habit to create a task/issue associated with more relevant changes, specially if you are a newcomer. In such a way other developers will be informed of your intention of implementing a new feature or fixing a bug and will avoid overlapping efforts, at same time allowing other developer to contribute to your task by adding useful knowledge and alternative approaches.

1 A first time developer

It is perfect understandable if you are approaching this for the first time, with a burning desire to solve a specific musical dilemma with code. Treat it as an opportunity to learn. It is a process that can, at first, appear overly involved and, perhaps, a little bureaucratic, but there are good reasons for the approach that's taken. It has succeeded to keep track of enormous code bases securely, sometimes in the face of actively hostile actions by others. It is this very characteristic that means that many open source projects operate that way, and may give people an insight into quite what 'open source code visible to all really' means for us. Also this robustness should resolve you of fears about 'doing some damage'. This well walked path of forking a repository, and making a Pull request protects you the community from yourself in an agreed fashion. This project, Zynthian, is based predominately in the python language with various whirling bits of C & C++ doing the heavily mechanical tasks down in the bowls where life is cheap, and code turns precisely. The python is a much more starter friendly world where you define what you want to do, and this gets translated into the sort of coal one can feed into the boilers down below.

1.1 So why might you want to write some code for a zynthian?

Probably to do something with a particular piece of equipment that you want to customise to aid you in your sound based endeavours. The output of MIDI based equipment presents it's self easily to a python code base that allows messages to be detected in an orderly fashion and then pretty much any aspect of the zynthian can be modified to obey your will. This has grown up from user dialog within the forum which is an excellent place to start with questions, suggestions and the truly crazy range of things people do with these machines.

1.2 Can I do damage to MY zynthian with the code I write ?

Yes, absolutely. With power comes responsibility.

But there is an important distinction between hardware and software. You can produce an inoperable zynthian with a badly placed code edit, but, you can't actively mechanically damage the machine itself by typing garbage. You simply correct the code fault and the damage its done, or at worst put in your backup ssd and things are good again.

This doesn't mean plugging the output of your 100W amp into the audio input of a zynth isn't going to damage it. It will and that's the world of hardware...

It's an important distinction.

1.3 How is code of the zynthian maintained?

You can log onto a Zynthian itself as the root user if you have the password (it's set to raspberry), but you might well change it on a performance machine. People will find it very amusing to log onto your machine pre or during performance if they can, and if you don't change the password....

You and they (if you haven't changed the password) can, and do pretty much anything you want as it it nothing more or less than a raspberry Pi of various vintages running an operating system. So you can edit files to your hearts content and very quickly render your Zynthian unplayable if you don't know what you are doing. There is an entire linux world built around what is called a terminal, which contains a command line that you literally type commands into and press enter to get them todo things. Zynthian has one of these,

and there are code editors that operate entirely round the command line, allowing you to change the contents of files on the machine.

Here there is no protection. it's your machine and you can break it as you wish, and whilst you will almost certainly get help on the discourse forum, this is not the sort of activity to indulge in twenty five minutes before your performance. It easy to become the essential technician beloved and feared in equal measure, but probably the first concept to learn is stable . . .

Stable is the particular branch of code that is know good and behaves in a fashion that will match the documentation. It wont be cutting edge, but it will behave itself, precisely as you expect, during the performance so this is what you should be initially taking on stage.

The good news is if you can get enough of a Zynthian running to open up it's inbuilt webserver, forever known as webconf in these parts, you can select an option that will allow you to return to the stable state. This is your protection from your own misdeeds with code. In fact it is sensible to keep at least two ssd's with a known good stable version on so you can give the zynth a brain change and keep a separate ssd for your code projects, but if you trash a part of webconf, then you have little or no easy way onto the machine, and you will need your backup... You have been warned!