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

Merged

https://github.com/monome/libavr32/pull/18

https://github.com/monome/diet-asf/pull/2

Squashed and merged

https://github.com/monome/teletype/pull/53

Other modules

PR for whitewhale…
https://github.com/monome/whitewhale/pull/6

Issues for earthsea and meadowphysics

https://github.com/monome/earthsea/issues/11

https://github.com/monome/meadowphysics/issues/5

2 Likes
#53

necrobump for an avr32lib merge! Aleph midi in operator seems somewhat buggy - hopefully this isn’t something that’s been introduced through recent contributions (but I don’t believe this is the case)

I think the way forward is try to rebase my dev branch on top of @zebra’s avr32lib PR. Did it before, only broke serial protocol, I’m not using that, so I’ll fix it back up later… here goes nothing!

1 Like
#54

The midi output handling in libavr32 is completely untested and very possibly incomplete (my fault IIRC). I should get that fixed up really. If there was a particular fork/commit post libavr32 integration that at least compiled I can certainly go back in and finish the cleanup, testing both input and output.

aside: I’m currently trying to wrap my head around what MPE means to the ansible firmware and as a result I may tweak some of the midi bits in libavr32 further.

#55

also not as interesting a feature without usb hub support imo! But we have three interesting synth modules on aleph now, I want to try using them as components in a midi/modular rig… Nonetheless I’ll test out the midi output while my head’s in it.

EDIT:

yarroooooooo!!! it works, it works, it works! Here’s the branch I’m running on my device:

2 Likes
#56

by works do you mean MIDI in/out functions or just your rebased changes on top of the libavr32 change?

#57

both! I rebased on top of ezra’s avr32lib branch, and this magically fixed the midi in operator. Before merging with avr32lib, op_midinote was kind of firehose-ing, banging the BEES net every time the op poll-ed. This was pretty easy to see using the new ‘output visibility on play screen’ feature.

Nothing unexpected seems broken so far - pretty stoked!

1 Like
#58

Just fixed the following regressions on the aleph boqs/dev branch due to libavr32 transition:

EDIT:

2 Likes
#59

So there is actually a compelling use-case for aleph midi output without simultaneous grid. That is a midi clock source - I could use the aleph as an algorithmic auto-accompaniment box for guitar & have my looper sync to it! could jam for a bit on dsyn/whitewhale setting up patterns, switch the USB grid to midi & start laying down guitar stuff synced to the looper & tapdance through the patterns (also over midi). All the building blocks for this are in place apart from the midi output…

It seems upon first test that aleph midi output is broken post-libavr32 merge. Judging from the log messages, @zebra never got it fully working (https://github.com/monome/aleph/commit/05cb09ba22811b9d148965cc4205864bd23f8089) but I haven’t tested pre-libavr32-merge midi output capabilities.

I’m about to pull-request a huuuuuge dump of aleph code from boqs/dev to monome/dev (including libavr32 merge & all the skektek new ops). That branch is not only compiling, think I’ve now fixed all the regressions.

If you do have some time to help fix midi output that would be totally awesome and much appreciated! Bit scared of the usb layer tbh, but I might have a look into this myself… Lots of other testing to be getting on with…

#60

I’m more than happy to get MIDI output all working. I hadn’t yet had a need for it and was hesitant to invest the time until it was clear that the future of the aleph code base was to switch to using libavr32.

1 Like