Page MenuHomeFreeBSD

[NEW PORT] audio/midi-matrix-lv2: LV2 'Midi Matrix' plugin bundle: 'Channel Filter'
ClosedPublic

Authored by ultima on Aug 17 2017, 6:16 AM.

Details

Summary

The Midi Matrix (Channel Filter) is a 3-in-1 filter plugin with a simple UI
enabling you to easily accomplish:

  • MIDI channel filtering (e.g. blocking of specific channels)
  • MIDI channel multiplication (e.g. send events from channel X to channels X, Y and Z)
  • MIDI channel rerouting (e.g send events from channel X to channel Y)
  • And any possible combination thereof

WWW: http://open-music-kontrollers.ch/lv2/midi_matrix

PR\: 221344
Submitted by\: Yuri Victorovich (maintainer)
Reviewed by\: lifanov (mentor), matthew (mentor)
Approved by\: lifanov (mentor), matthew (mentor)
Differential Revision\: https://reviews.freebsd.org/DXXXXX

Test Plan

portlint:
looks fine.

poudriere:
103i386
103amd64
110i386
110amd64
12i386
12amd64

Diff Detail

Repository
rP FreeBSD ports repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

ultima created this revision.Aug 17 2017, 6:16 AM
ultima added inline comments.Aug 17 2017, 6:18 AM
audio/midi-matrix-lv2/Makefile
7 ↗(On Diff #32156)

This is ugly, is there a better way to implement this? I couldn't come up with any.

mat added inline comments.Aug 17 2017, 11:27 AM
audio/midi-matrix-lv2/Makefile
7 ↗(On Diff #32156)

I have been pondering adding a USE_GITLAB to the framework, have not found the time yet, though.

matthew accepted this revision.Aug 17 2017, 5:57 PM

lgtm

audio/midi-matrix-lv2/Makefile
7 ↗(On Diff #32156)

It might be ugly, but there's no alternative and it works.

This revision is now accepted and ready to land.Aug 17 2017, 5:57 PM
ultima added inline comments.Aug 17 2017, 7:27 PM
audio/midi-matrix-lv2/Makefile
7 ↗(On Diff #32156)

I'll create a draft, I'm not sure if adding USE_GITLAB and reusing the code for github is the better solution though. Simply adding a new variable that will change the root domain like: GH_DOMAIN, or GH_SITE and setting it to https://gitlab.com. The latter also has the benefit of allow users using gitlab on there own domain to be set so it maybe a better solution.

It could be a little more confusing to not have the variable as GITLAB though, so maybe it would be best to create a new USE with the domain change option. This is probably the best solution.

Thoughts?

ultima added inline comments.Aug 17 2017, 7:29 PM
audio/midi-matrix-lv2/Makefile
7 ↗(On Diff #32156)

's/root//' I wish I could edit the comment.

This revision was automatically updated to reflect the committed changes.
mat added inline comments.Aug 18 2017, 7:53 AM
audio/midi-matrix-lv2/Makefile
7 ↗(On Diff #32156)

Adding USE_GITLAB, with GH_SITE, GH_ACCOUNT, GH_PROJECT, GH_COMMIT is what I had in miond :-)
Reusing the USE_GITHUB bit also, but not too much, they look the same, but are very different :-)
It should be named GITLAB because it would work with the gitlab application, wether it is on gitlab.com, or on a personnal installation.

ultima added inline comments.Aug 18 2017, 8:31 AM
audio/midi-matrix-lv2/Makefile
7 ↗(On Diff #32156)

Yeah, wish you could have replied about 4 hours sooner. Realize just how different the two are... Not a complete loss though I understand the USE_GITHUB code much better now. Your plan sounds good, one question though what is the reason for adding GH_COMMIT over reusing GH_TAGNAME?

mat added inline comments.Aug 18 2017, 8:39 AM
audio/midi-matrix-lv2/Makefile
7 ↗(On Diff #32156)

Ah, I mistyped, habits, I meant GL_ prefix for each. And it needs a GL_COMMIT because it is needed because WRKSRC contains the commit hash. So as it is required anyway, might as well have it. (And no, I really do not think a post-extract target moving things around is the way to go.)