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.
Tags
None
Referenced Files
Unknown Object (File)
Feb 20 2024, 12:05 AM
Unknown Object (File)
Feb 19 2024, 5:10 PM
Unknown Object (File)
Feb 19 2024, 5:10 PM
Unknown Object (File)
Feb 19 2024, 4:57 PM
Unknown Object (File)
Jan 15 2024, 9:12 PM
Unknown Object (File)
Dec 20 2023, 5:09 AM
Unknown Object (File)
Nov 8 2023, 12:52 PM
Unknown Object (File)
Oct 9 2023, 4:26 PM
Subscribers

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
No Lint Coverage
Unit
No Test Coverage
Build Status
Buildable 11126
Build 11508: arc lint + arc unit

Event Timeline

audio/midi-matrix-lv2/Makefile
7

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

audio/midi-matrix-lv2/Makefile
7

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

lgtm

audio/midi-matrix-lv2/Makefile
7

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
audio/midi-matrix-lv2/Makefile
7

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?

audio/midi-matrix-lv2/Makefile
7

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

This revision was automatically updated to reflect the committed changes.
audio/midi-matrix-lv2/Makefile
7

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.

audio/midi-matrix-lv2/Makefile
7

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?

audio/midi-matrix-lv2/Makefile
7

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