#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.

#49

Thanks, I’ve had a quick look through the libavr32 changes, seems pretty straightforward. I’ll try and test on the teletype (and maybe some other modules) later this week.

#50

Okay I’ve tested on teletype and it works fine.

I’ve also tested on whitewhale…

https://github.com/samdoshi/whitewhale/commit/65beb4e1faa344292baeef15c2f1d6d3f8320878

@zebra can you double check my whitewhale commit before I open up a PR.

Haven’t tested on Ansible, or any of the other trilogy modules.

I’m happy for the PR to be merged, I can create tracking issues in each of the modules to fix the breaking changes.

Want me to hit the buttons?

1 Like
#51

Hello all, if I don’t hear otherwise I’m going to merge the libavr32 PR. I’ll also make the change for the other modules too.

It’ll be either tomorrow or Wednesday. Hope that’s okay.

3 Likes