#29

That’s fine. I can always trigger a retest once the libavr32 changes are in.

:smiley: ah, the joy of C. I suppose we could try and get travis to use -Werror, but that seems to be a bit of overkill.

.gitmodules is only used for git clone --recursive and git submodule init, from then on it only cares about hashes matching up, not where they come from. The trick to getting around your problem is to add the submodule pointing at monome/libavr32, but then change the remote of the submodule to your fork.

e.g. (untested)

git submodule add https://github.com/monome/libavbr32
cd libavr32
git remote set-url origin git@github.com:catfact/libavr32.git
git remote add upstream git@github.com:monome/libavr32.git
git pull

Fundamentally, git really doesn’t care where stuff comes from, only that commit hashes match up. So if someone clones your repo, they will have to make sure that their libavr32 submodule has the required commit available, either by manually fetching it from a remote, or waiting for those changes to be merged in.

One really helpful snippet for everyones ~/.gitconfig is

[url "git@github.com:"]
    ;; e.g git remote add gh:samdoshi/my_repo
    ;;;    git clone gh:samdoshi/my_repo
    insteadOf = gh:

Thus my workflow for testing your changes is:

cd <path>/teletype
git remote add catfact gh:catfact/teletype
git fetch catfact
cd libavr32
git remote add catfact gh:catfact/libavr32
git fetch catfact
cd ..
git checkout catfact/aleph-libavr32
# ..... oops?

Oops, looks like libavr32 commit 885a64 hasn’t been pushed to GitHub yet…


https://github.com/catfact/libavr32/tree/885a64afe42cc89bc4f59d72ffd10d8f97dd72ce

Another handy thing for your ~/.gitconfig

[status]
    submoduleSummary = true

Gives a git status of:

HEAD detached at catfact/aleph-libavr32
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   libavr32 (new commits)

Submodules changed but not updated:

* libavr32 885a64a...8f04e5b:
  Warn: libavr32 doesn't contain commit 885a64afe42cc89bc4f59d72ffd10d8f97dd72ce

no changes added to commit (use "git add" and/or "git commit -a")
#30

ok this all sounds awesome!

Ha! There was me thinking master was basically an abandoned branch… Need to have a look at that merge to get a sense of it. Hairy merges are probably inevitable in coming months, time to dust off those magit merge chops!

umm yea can we make this, like, the last job? Personally don’t care about code formatting - appreciate it may help readability for some. From my side, aleph is the only readable large codebase I ever worked on - everything else > 10000 lines I ever worked on was a horrific brain-damaged mudball top to bottom. Running clang-format on everything will majorly mess with any subsequent merges so let’s get all feature branches & testing out the way first. Other than that, happy to use the auto-formatting if it helps others!

umm yea - this! I’ll get the ball rolling tonight with a couple hours systematic testing of the net-use-malloc branch I pull-requested. Kind of feel like I’ve been guilty of bikeshedding BEES strategy last couple of weeks, haven’t touched any of the code :zipper_mouth:. Ease back into it gently…

#31

cool, that’s what i figured. but i didn’t think it through originally, so my aleph fork was pointing at my libavr32 fork from the beginning, with monome/libavr32 added as upstream. i wondered how to change it after the fact… seems like it works to just edit .gitmodules and then run git submodule sync …? (which i have since done and pushed.)

Oops, looks like libavr32 commit 885a64 hasn’t been pushed to GitHub yet

ach, sorry. that is some useless merge commit arising from so much mucking around between all these different repos. rolled teletype to point back at 93241e and pushed.

I suppose we could try and get travis to use -Werror, but that seems to be a bit of overkill.

agreed… i guess the moral is that it behooves us to pay attention to the output on travis, and not just whether it passed.

Ha! There was me thinking master was basically an abandoned branch…

:laughing: well it kinda was. i haven’t added anything useful to avr32 in a good long while; everything else i’ve added to dev is silly experiments that haven’t gone anywhere useful and involve totally different parts of the tree. i gotta look more carefully at what the current upstream differences even are between master/dev…

but first i actually want to test your DSP pull request, cause it sems actually useful.

#32

ok well I stand by that part - it has been tested and does work (as far as I know/understand!) - need to double check this still works:

https://github.com/rick-monster/aleph/blob/dev_rebased/dsp/filter_svf.c#L150-L157

What happens to dsyn though? Isn’t half the point of dsyn that the filters are always kind of glitching out & going crazy? Never tried to wrap my head round the code, only played with the shiny confusing dials on that module from user p.o.v. An evening of testing/playing through the aleph will probably be pretty fun! So I’ll report back testing on those two pull-requests…

#33

ha, yeah i do actually kind of enjoy the RQ wrapping in dsyn context.

the main thing is that at high Q, the SVF should be dang close to a sine oscillator.

#34

yup - see these sound samples demonstrating adsr VCA/VCF (that old chestnut):


code ‘sounds’ the same on aleph as linux. If you import those .wav files to ardour & look at the waveform, you can see the high Q filter ringing at the cuttoff frequency, as it sweeps down.

It certainly scared my cat! will add back in the old code as a feature on that PR…

I’d also advocate strongly for arbitrary op deletion/insertion. This is genuinely useful! But yea - lots of experimenting/learning on my dev branch(es) not everything was necessarily a good idea. Man, synth control is hard!

2 Likes
#35

briefly glancing at the commits, this looks fantastic. i can’t do any hardware testing until saturday, so if someone else judges everything to be in good order feel free to merge. otherwise i’m happy to run trials later on.

1 Like
#36

Actually merging into dev & getting everyone using/testing features which work > 95% of the time may be the only way we get enough alpha testing to figure out whether things work 100% of the time…

I suggest the approach of squashing down pull-requests into the minimum number of commits so we can always change it back. And the award for most insane/unhelpful gitlog goes to… errr my net-use-malloc PR!

#37

i am glad we’re having this conversation.

i realize basing the refactor off master is a bit “wrong.” my thinking was that it would just be easier to deal with fallout from the refactor against the most known possible version (what most people are running) and deal with merging new features as a separate process.

i’m totally down to do this a different way. at worst, it’s really not that hard to redo the refactor on top of dev, now that i know what’s needed.

our old strategy was that the tip of master should always be tested and never ahead of of the latest release tag. at this point, i have doubts about the efficacy of this, because it seems to result in the piling-up of an unmanageable number of untested features on the dev branch. (and yeah, this is totally my fault.)

so i guess i’m proposing that we aim for more frequent integration of the dev and master branches? maintain both a ‘stable’ and a ‘testing’ release, both downloadable? i dunno.

1 Like
#38

hummm, so I guess the version everyone’s using is latest master HEAD? Seems like the time is right for a new aleph release containing all the new goodies on dev branch. Doesn’t seem to me anything’s really gone wrong with the management of branches, we just need to get a release out, get it tested, then maybe merge to master once a reliable release makes it through testing. Not the end of the world - ‘unmanageable’ amount of new features means at least few cool new features, right?

We can just revert any features on dev that’re not so cool…

#39

agreed. actually i was looking at the wrong thing for a moment there - hadn’t pulled in upstream master changes to my fork in quite some time. so it’s not quite as rough as i thought.

there are 650-odd commits (more than github will display, apparently):
aleph-commits-master-dev-20161031.txt (63.3 KB)

so… it’s doable. these can be sorted into categories:

  • you did a bunch of cool stuff with the serial protocol
  • you added a bunch of DSP and some new modules
  • i added some unfinished block-processing modules
  • i added some abortive/useless c++ wrappers for bees, and made some changes to bees source to allow this
  • there are a couple of useful, discrete bugfixes scattered in there (e.g. fixed op_gate pickling.)

so… yeah this could use a big rebase, it’s very hard to sort through.

we should try to separate the stuff that impacts code in avr32_lib and code in bees (probably your serial features mostly)… that’s the stuff that will come in contact with the libavr32 migration.

the DSP additions are just that - additions, that shouldn’t really impact anything else, but will be great fun to play with.

to be honest, i’m not really sure of the next step. maybe we should trade rebases somehow…

#40

Not really catching your drift here? Do you mean squash my many commits on monome/dev to one commit per new feature? I’m getting pretty good at that workflow after squashing down my DSP PR - easy enough to save the original branch & diff to check the rebase HEAD is identical…

ok yea so for starters if I squash down the new serial features on monome/dev into one commit for BEES, one for avr32lib, would that help?

Also rember now it would be really useful & really not much work to implement a BEES -> OSC bridge in C, allowing other people to actually use the serial protocol…

#41

squash my many commits on monome/dev to one commit per new feature?

yeah, i guess i mean something like that. i’d like to get the useful new stuff into a release. experimentally, i tried merging dev into master, and blew myself up pretty good.

i’m just suspecting that the easiest way to move forward will be to make new rebased branch(es) specifically for merging onto master, rather than trying to merge dev and master at this point. then i can reconcile those feature branches with the libavr32 refactor, one way or another.

if I squash down the new serial features on monome/dev into one commit for BEES, one for avr32lib, would that help?

yeah i think so

now it would be really useful & really not much work to implement a BEES -> OSC bridge in C

absolutely, i very much want to start doing this myself.

#42

guessing the problem was merging dev into master on top of your recent avr32lib refactor? As far as I could see master is no commits ahead of dev, so should be no prob!

#43

no, it wasn’t that, but maybe something equally stupid, i’ll have another look

… oop, ha, yes. on previous attempt i had run clang-format on my fork’s dev. i’m a fool

so yeah, nevermind! merge is clean

#44

btw I also added this uncontroversial, well-tested new feature:
https://github.com/monome/aleph/issues/246
Wouldn’t want to lose that!

1 Like
#45

you probably saw, but i went ahead and merged PR #266 after fixing lines/dsyn makefiles.

#46

Yea I saw that - awesome!

OK so even though dev->master merge would be clean, squashing down serial features into one/two commits would obv still be good. Hopefully easier than it looks - I’ll get back to you on that! Are we inviting trouble rebasing hard on dev? (I don’t think so!)

1 Like
#47

are we inviting trouble rebasing hard on dev

probably not really (not a lot of people working with dev), but that’s why i mentioned rebasing to a new branch first.

the other reason to rebase is that it would maybe be better to only merge the stuff into master that is actually useful (most of your chnages) and not totally unfinished stuff (most of my changes) … but maybe it’s not really a big deal.

#48

I like the original suggestion to swap rebase branches best. First I will try to squash out serial features into a sane number of sequential commits with human-readable log, then maybe all the bfin emu commits if that isn’t too tough, then I’ll try to move everything useful directly on top of master, with your bits on top of that. Then over to you to edit your commits if necessary…

This approach is much harder to screw up & lose working code than cherry-picking on a new branch, because you always have an acid-test that the HEAD of dev_rebased must be identical to the old dev HEAD… Anyways I need to try but think that will work…

EDIT:
Hang on no, waiiiit! Rebase/cleanup of the dev branch at this stage would totally screw up my other PR - obviously! Can we run things in the following order:

  • first I squash the commits in that PR down to one/two commits
  • then I rebase it on top of monome/dev
  • then perform the rebase described above on my net-use-malloc branch (for the old commits with bad log)
  • then over to you if you want to edit block processing/C++ wrappers, clean up bugfixes etc
  • then merge catfact/net-use-malloc~1 into monome/dev (i.e everything up till the net-use-malloc commit)

Then I can force-push catfact/net-use-malloc to rick-monster/net-use-malloc.rebased, do a final check it’s identical to rick-monster/net-use-malloc, then re-open the pull-request from rick-monster/net-use-malloc.rebased to monome/dev.

Phew! That sounds a lot more complicated than it actually is, sorry! The other option is we just leave the commits on dev a mess, and hope like hell none of it needs to be subsequently reverted.