written by: jsn
+1 On Reviewing - it would be useful to get feedback on whether our code is a 'good citizen'. I'm still head-scratching about memory allocation and passing stuff between fast/slow threads. Happy to wrtie up notes on good/bad technique if given rambling feedback :-)I've merged the Noise and VU Meter agents from their respective branches into master.
I've also put the tools into the top level, and took the liberty of tweaking the builds so that they use tools/ from that directory. Plugins can be build from their individual directories or from the top level. Everything is building OK on Windows and Mac OS.
You'll want to merge up with master. From now on, I won't pull changes onto master: You should push changes onto it when you are ready.
Ok. This took me by surprise and confused me for a few minutes :-)
What is the "good practice" here? Should we always work in branches per agent-under-development ? Can we get a Wiki page set-up with the "correct" practice of branching/merging/pushing changes so we are all clear?
Looks like EigenD-Examples needs to be updated to match this new pattern (i.e. change to Makefile)
I did it just this once just to get it bootstrapped. I won't mess inside anyone's directory any more.
The idea would be to have master be the shared branch, where everyone keeps their idea of 'released' code.
We (Thats the Eigenlabs We) will keep another branch in due course, for release purposes. We'll pull changes
from master onto that branch.
We've recently had a debate here about whether this 'One Contrib Repo for All' is really the best thing, verses
everyone having a repo of their own per project, and us trying to pull from them into an Eigenlabs Contrib.
Single repos have their advantages (you aren't fighting with other people) and disadvantages (less community feeling)
A shared repo also introduces the possibility of shared code in dll form. (ie, think fft libraries or voice recognisers)
EigenD would need some tweaking for this, but wouldn't be too hard.
I think we have to see how it goes to find the best tradeoff between git-nerdism and convenience.
I've started a page Here. Feel free to add to it. As John (L) pointed out, we're feeling our way into this and we'll have to see what works and what doesn't.
Hmm, I think the idea of a stable master is essential. I like the idea of one repo for all. I also think that some sort of review prior to merge would be good, particularly in these early days. If only to ensure we're all moral devs ;-)
Also, thanks Jim for the git summary.
D
+1 On Reviewing - it would be useful to get feedback on whether our code is a 'good citizen'. I'm still head-scratching about memory allocation and passing stuff between fast/slow threads. Happy to wrtie up notes on good/bad technique if given rambling feedback :-)
+1 on Shared Repo (hence the 'practice' page request - which looks good. Thanx Jim!)
Please log in to join the discussions
UK
