diff --git a/.drone.yml b/.drone.yml deleted file mode 100644 index d0541de..0000000 --- a/.drone.yml +++ /dev/null @@ -1,47 +0,0 @@ -kind: pipeline -name: build - -trigger: - event: - - push - branch: - - main - -steps: - - name: docker-default - image: plugins/docker - settings: - registry: git.riksolo.com - username: riksolo - repo: git.riksolo.com/${DRONE_REPO,,} - tags: - - latest - - ${DRONE_COMMIT} - password: - from_secret: dockertoken - - - name: docker-rblicht - image: plugins/docker - settings: - registry: git.riksolo.com - username: riksolo - repo: git.riksolo.com/${DRONE_REPO,,} - build_args: - - SITE=rblicht - tags: - - latest-rblicht - - ${DRONE_COMMIT}-rblicht - password: - from_secret: dockertoken - - - name: trigger docker-compose release - image: plugins/downstream - settings: - server: https://drone.riksolo.com - token: - from_secret: drone_token - repositories: - - RikSolo/docker-compose - depends_on: - - docker-default - - docker-rblicht \ No newline at end of file diff --git a/.gitea/workflows/build.yml b/.gitea/workflows/build.yml index 0fd5c20..5f3c3cf 100644 --- a/.gitea/workflows/build.yml +++ b/.gitea/workflows/build.yml @@ -1,5 +1,8 @@ name: Build -on: [workflow_dispatch] +on: + push: + branches: + - main jobs: Deploy: @@ -13,17 +16,8 @@ jobs: url: ${{vars.NODE_RED_WORKFLOW_STARTED_URL}} data: '{"job": ${{toJSON(job)}}, "gitea": ${{toJSON(gitea)}}}' - - name: Install LFS - run: | - curl -s https://packagecloud.io/install/repositories/github/git-lfs/script.deb.sh | bash - apt-get update - apt-get install -y git-lfs - git lfs install - - name: Checkout - uses: actions/checkout@v4 - with: - lfs: 'true' + uses: actions/checkout@v3 - name: Docker install run: | diff --git a/Dockerfile b/Dockerfile index 5b64798..781c554 100644 --- a/Dockerfile +++ b/Dockerfile @@ -1,9 +1,6 @@ FROM node:22 WORKDIR /usr/src/app -ARG SITE=default -ENV SITE=$SITE - COPY package*.json ./ RUN npm install ADD . . diff --git a/content/_data/site.js b/content/_data/site.js deleted file mode 100644 index e6bccc5..0000000 --- a/content/_data/site.js +++ /dev/null @@ -1,8 +0,0 @@ -export default function () { - return { - title: "Rik Berkelder", - url: process.env.site == "rblicht" ? "https://rblicht.nl" : "https://riksolo.com", - author: "Rik Berkelder", - site: process.env.SITE || 'default' - }; -} \ No newline at end of file diff --git a/content/blogposts/2021-04-22-SE215.md b/content/blogposts/2021-04-22-SE215.md new file mode 100644 index 0000000..39e3f0a --- /dev/null +++ b/content/blogposts/2021-04-22-SE215.md @@ -0,0 +1,29 @@ +--- +slug: "shure-se215-opinions-2021-04-22" +title: "Opinions on the Shure SE215 In-Ear Monitors" +date: "2021-04-22" +modified: "2021-04-23" +description: "Personal thoughts on a pair of in-ears I bought." +eleventyExcludeFromCollections: true +--- +Disclaimer: This should not be trusted as a review. While I enjoy good audio, I am by no means an expert. + +I have recently invested in a pair of Shure SE215 IEMs and have had some mixed feelings about them. You might think that mean I don't like them, or that that's a bad thing; That's not true. Allow me to explain. + +The Shures are by far the least "Flat" or "Reference" listening devices I own. This is absolutely okay, because they weren't made to be. They were made, first and foremost, to passively block out as much as the outside world as possible. That's one of the main reasons I bought them, and they do an outstanding job of it. Whenever I put these in, put on some music and go outside for a walk, it's just me and the music. And I'm not talking about blasting music into my earholes so loud I can't hear anything else anymore. The passive isolation on these in-ear monitors allows me to put on music on a relatively quiet level and block everything else out. This allows me the freedom of actually choosing how loud I want my music to be. + +These in-ears make a lot of music I listen on them sound absolutely stellar. They have a surprising amount of soundstage for something that isolates this well, and the detail in them is quite great. They have a bit of a peak around 5kHz. In a lot of cases this adds detail to the sound, and has a tendency to bring out the snare drum, hi-hat and cymbals a bit more than a flat headphone would, which I personally quite like. + +These in-ears work very well for pretty much anything I listen to, going from Rush to Greta van Fleet to Pendulum to Infected Mushroom. But then I put on Nightwish's Imaginaerum, and that's where the mixed feelings began. I'll admit I'm pretty treble sensitive. But besides the lead guitar becoming piercing and quite annoying at higher volumes, I lost so much detail in the track as a result of it. The problem here is that modern metal tends to get mixed and mastered in a very aggressive way, and with the sound already being so full and maxed out the 5kHz peak in these makes a lot of things fall apart. This isn't a problem with the in-ears, and it's not a problem with the music, but it's a problem with combining them. + +This isn't universal across all metal, and not exclusive to metal. It all depends on how the specific music is mixed and mastered. While I ran into this with bands like Nightwish and Sabaton, I had no problems listening to Iron Maiden and Eluveitie. It seems to occur more on music with more modern production, but your mileage may vary. + +Gladly, it's not hard to set up a decent equalizer on both my desktop and my phone (using Poweramp for android), and taking away some of that 5k peak fixes most of the problems on the tracks where they happen. This is by no means an equalization I'd keep turned on all the time, only opting to use it in the places where it's needed, and letting the natural beauty of the sound shine where it isn't. + +One upside of the frequency response of these in-ears is that it does compensate for the imbalance in the frequencies that they manage to passively block. So, in louder environments (like on stage, where these were designed for), you'll always be able to hear what's going on inside them over the noise that does manage to come through the passive isolation. + +Another source of mixed feeling is how sensitive these headphones are. They have an impedance of 17Ω. This, in laymans terms, mean that they don't require a lot of power to drive. For reference, most consumer-focussed headphones sit around 32Ω. This, in theory, is a very good thing. They take less power to drive, so they'll work on pretty much everything you can come up with and drain battery-powered devices less quickly. There's a downside to all of that efficiency though: noise floor. Because they are so sensitive, they're very prone to picking up any noise from devices you connect them to. While being fine for every other pair of headphones I own, my trusty OnePlus 6 has a bit of (barely) audible noise when there's a quiet spot in the music. It's definitely not a deal-breaker, and should be fixed by getting a dedicated output device. + +This is more of a problem with my playback devices than with the headphones themselves, but it is something to keep in mind if you're looking to pick them up and use them with your phone, laptop or other devices. + +All in all, I'm very happy with these in-ears. While they're definitely a sidegrade to some of the other ones I own, their build quality, passive isolation and ability to make certain tracks absolutely shine make them a very welcome addition to my collection. diff --git a/content/blogposts/2024-05-04-grandma3-fader-feedback.md b/content/blogposts/2024-05-04-grandma3-fader-feedback.md index b384ff0..2801284 100644 --- a/content/blogposts/2024-05-04-grandma3-fader-feedback.md +++ b/content/blogposts/2024-05-04-grandma3-fader-feedback.md @@ -45,4 +45,4 @@ On top of this, assuming you set the inputOSCName variable correctly, MA3 will b # Support I maintain this plugin in my free time. This plugin is available free, and the code is free for you to edit. If you have any issues with the plugin, feel free to contact me through the contact info on this website, but please don't expect me to respond right away. -If this plugin makes your life better, you can consider buying me a beer through [ko-fi](https://ko-fi.com/riksolo) \ No newline at end of file +If this plugin makes your life better, you can consider buying me a beer through [ko-fi](https://ko-fi.com/riksolo) diff --git a/content/blogposts/2025-02-24-ma3-tip-clear-through-black.md b/content/blogposts/2025-02-24-ma3-tip-clear-through-black.md deleted file mode 100644 index aac8f3f..0000000 --- a/content/blogposts/2025-02-24-ma3-tip-clear-through-black.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -slug: "ma3-tip-clear-through-black" -title: "MA3 Tip: Clear Through Black" -date: "2025-02-24" -modified: "2025-02-24" -description: "A little GrandMA3 Macro to clear fixtures in the programmer in a more subtle way." ---- -When I'm busking on GrandMA3, especially for slower, more looks-based shows, I keep making a specific kind of mistake. With Program Time turned on, clearing a fixture will fade all of it's parameters. So hitting good old clear clear clear means fixtures I've turned on will fade out, while also changing colors, gobos, zoom, position and so on. That feels quite sloppy and distracting to me. Especially since the whole point of using the programmer for busking, to me, is being able to make small changes subtly. - -I've found myself dimming the fixture to 0, `Off`ing all the other parameters, and then clearing the fixture so you only see it fade out (and potentially back in if it was already on) without seeing a whole bunch of other stuff change. That's quite a lot of manual work, so I started wondering if I could write a little macro that does this for me. - -That macro ended up looking like this: - -| Command | Wait | Note | -| --------------------------------- | ------ | ------------------------------------ | -| At 0 Fade "1" | 1 | Dim fixtures | -| Off Selection If Attribute 2 Thru | 1 | Clear attributes except dimmer | -| Attribute At Release Fade 1 | 1 | Set fixtures to original intensity | -| Off Selection | Follow | Clear release values out of fixtures | - -If you want to use a different fade time, you'll want to not only change the `Fade` time in the first line, but also the wait times of the first and third lines. These wait times are there to make sure things only start clearing once the fixture is off, and to make sure the fixture fades back in before clearing the programmer entirely. The wait time of the second line makes sure that parameters that can't physically change instantly have some time to clear before fading the fixture back to it's playback intensity. - -In the above version of the macro, it only clears fixtures that are currently selected, which is what I've end up usually wanting. If you want it to clear the whole programmer, you could add a macro line all the way at the top containing `Clear; IfProgrammer`. This first deselects what you've currently got selected, so that anything you have selected that doesn't contain any programmer values doesn't dip to black for no reason. Then it selects every fixture that currently has programmer values. - -The last two steps might seem a little weird. why not just `Off Selection` right away? This is because Off doesn't (currently, as of 2.2.1.1) take any timing besides prog time into account. I prefer this macro working without prog time enabled (since prog time working the way it works being what drove me to figure out this little macro in the first place). - -I hope it helps you make your busking just a little bit smoother, like it's been doing for me. \ No newline at end of file diff --git a/content/blogposts/2025-09-09-ma3-tip-conditional-recipes.md b/content/blogposts/2025-09-09-ma3-tip-conditional-recipes.md deleted file mode 100644 index fa09f03..0000000 --- a/content/blogposts/2025-09-09-ma3-tip-conditional-recipes.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -slug: ma3-tip-conditional-recipes -title: "MA3 Tip: Customizing Shows On The Fly Using Conditional Recipes" -date: 2025-09-11 -modified: 2025-09-11 -description: Easily adapting GrandMA3 showfiles to different situations by bulk-toggling Recipe lines based on tags. ---- -Touring with a super detailed, highly programmed light show is great, until you find yourself having to adapt to more limited venues than anticipated. - -I found myself facing this problem earlier this year. A band I've been working with had mostly been doing big one-off festival shows, and not a huge amount per year. With those circumstances, it wasn't a big problem for me to manually go over the showfile for every show and fixing things that didn't really work with each festival rig. - -Until they booked a two week club tour through Europe, and while it was a big step for the band, the variety of venues ranged from tiny 100-capacity music places to the mainstage of a festival with 40,000 sold tickets. - -Spending a couple of hours per show doing previz would be possible, but I kept making more or less the same substitutions, which left me wondering if I could lighten that workload. - -## The easy option, and the engineering perspective -The first thought was to just build a second "minimal" showfile, for very small rigs. This would be a lot easier to scale up, but it would mean having two base files to keep up to date and program new tracks into. I absolutely hate doing repetitive work though, so keeping two separate showfiles up to date sounds like a pain. - -DRY (don't repeat yourself) is one of the first things hammered into you when you're learning computer programming. If you notice you're writing the same code multiple times, it means you can probably simplify something, or extract it into a reusable bit of code, so that when you change some part of it, it updates anywhere. A great example of DRY in lighting programming would be using presets in your show, instead of hardcoding values into every cue. So I started thinking if I could come up with a more elegant solution for my situation. - -## The elegant solution -The entire show has been programmed using recipes, and when I was thinking this problem through, tags were recently added into the MA3 software. I noticed that a Tag field was also added to the recipe lines I started wondering if I could bulk edit recipe lines that have a tag. And as basically any question about doing things in MA using commands, the answer was "of course!" - -I ended up with the following syntax: -` -Set Sequence 1 Thru Cue 1 Thru Part Thru.Thru Property "enabled" 0 if #[Tag 'No Sides'] -` - - This disables any recipe line in any cue in any sequence as long as it has a certain tag. change the 0 for a 1 and it enables it. So I created a few tags ("No Sides", "No Floor Spots", "No Floor Washes", and so on), then went through the show, adding additional programming for these situations. Then I just had to create a couple of simple macros to toggle the recipe lines on and off, and I was left with an on-the-fly configurable showfile to adapt to wildly differing show scenarios. - -## Takeaways and other uses -Being able to mix and match multiple options also lets me make sure to still maximize what I'm doing with the parts of a rig that are there. Had I chosen to go with a "minimal" showfile, using it when I don't have washes on the floor would also mean losing any cool stuff I was doing with the side lights, or having to manually program it back. - -This technique has saved me several hours per gig, most of which wouldn't have been paid either. - -This trick can be very useful when you're not touring too. I've also started using the `If Tag` technique in my busking showfile. For example for enabling/disabling certain groups in my LOS-inspired system. diff --git a/content/includes/highlights.njk b/content/includes/highlights.njk deleted file mode 100644 index 6097482..0000000 --- a/content/includes/highlights.njk +++ /dev/null @@ -1,11 +0,0 @@ - \ No newline at end of file diff --git a/content/includes/img. b/content/includes/img. new file mode 100644 index 0000000..e69de29 diff --git a/content/includes/navbar.njk b/content/includes/navbar.njk deleted file mode 100644 index 56eaef6..0000000 --- a/content/includes/navbar.njk +++ /dev/null @@ -1,31 +0,0 @@ -{% macro navItem(title, url, hyphen=true, target='_self') %} - - {{title}} - {% if hyphen %} - {% endif %} - -{% endmacro %} - -
-
- -
-
- {{navItem("Home", "/")}} - {%if site.site != "rblicht" %} - {{navItem("Blog", "/blog")}} - {%endif%} - {{navItem("Portfolio", "/portfolio", false)}} -
-
- | - {% if site.site != "rblicht" %} - {{navItem("Mastodon", "https://dook.business/@RikSolo")}} - {% endif %} - {{navItem("Instagram", "https://instagram.com/RikBerkelder", false)}} -
-
-
-
\ No newline at end of file diff --git a/content/includes/skills.njk b/content/includes/skills.njk deleted file mode 100644 index 838979f..0000000 --- a/content/includes/skills.njk +++ /dev/null @@ -1,21 +0,0 @@ -
-
- Lighting & AV - -
-
- Software & IT - -
-
\ No newline at end of file diff --git a/content/layouts/base-nonav.njk b/content/layouts/base-nonav.njk deleted file mode 100644 index b206e33..0000000 --- a/content/layouts/base-nonav.njk +++ /dev/null @@ -1,57 +0,0 @@ - - - - - - - - - - - - - - - - - - - - - {%if tags.includes("blogpost")%} - - {%if description %} - - - {% endif %} - - - - - {%endif%} - - - {% if title %}{{title}} | {% endif %}{{site.title}} - - - - - {{content | safe}} - - - - - - - - - \ No newline at end of file diff --git a/content/layouts/base.njk b/content/layouts/base.njk index e1f9f3c..ddb33a2 100644 --- a/content/layouts/base.njk +++ b/content/layouts/base.njk @@ -1,7 +1,72 @@ ---- -layout: 'base-nonav.njk' ---- +{% macro navItem(title, url, hyphen=true, target='_self') %} + + {{title}} + {% if hyphen %} - {% endif %} + +{% endmacro %} -{%include "navbar.njk"%} + + -{{content | safe}} \ No newline at end of file + + + + + + + + + + + + + + + + + {%if tags.includes("blogpost")%} + + {%if description %} + + + {% endif %} + + + + + {%endif%} + + {% if title %}{{title}} | {% endif %}{{site.title}} + + + +
+
+ +
+
+ {{navItem("Home", "/")}} + {{navItem("Blog", "/blog")}} + {{navItem("Portfolio", "/portfolio", false)}} +
+
+ | + {{navItem("Mastodon", "https://dook.business/@RikSolo")}} + {{navItem("Instagram", "https://instagram.com/RikBerkelder", false)}} +
+
+
+
+ + {{content | safe}} + + + + + + \ No newline at end of file diff --git a/content/layouts/portfolio.njk b/content/layouts/portfolio.njk index 48d2aeb..4682647 100644 --- a/content/layouts/portfolio.njk +++ b/content/layouts/portfolio.njk @@ -4,25 +4,15 @@ layout: base.njk

{{title}}

- {{timeframe}} {{description}} <- Back to overview {{content | safe}}
-
+
{% for image in data.images %} - - - {% if image.caption %} -
- {{image.caption}} - - {{image.date | dateLocale}} -
- - {% endif %} - + {% endfor %}
diff --git a/content/pages/cv.njk b/content/pages/cv.njk deleted file mode 100644 index 3c2054d..0000000 --- a/content/pages/cv.njk +++ /dev/null @@ -1,43 +0,0 @@ ---- -title: CV -permalink: "/cv/" -layout: 'base-nonav.njk' -draft: true ---- -
-

Rik Berkelder

- Lighting Designer/Technician | Software Engineer | Nerd - -

About

- -

- I am a freelance lighting designer, technician, and systems specialist with a focus on touring productions and live - performance. Since 2018, I have worked freelance, initially alongside a career in IT and software engineering and - full time since 2022, bringing together technical precision, creative design, and a strong respect for the craft and - crew. -

- -

- I have designed lighting for touring shows that require both creative adaptability and practical problem solving on - the road. As a house and systems technician in a variety of venues, I regularly support international acts and - crews, adapting to varied - setups and workflows. My theatre and festival touring experience has also strengthened my ability to communicate - clearly with local teams and deliver consistent, high quality results in dynamic environments. -

- -

- A perfectionist by nature, I value preparation, attention to detail, and reliability while staying flexible and - collaborative to meet the demands of live production. My background in IT and network management supports - increasingly complex lighting and control systems, ensuring stable and efficient operation across all types of - venues. -

- -

Skills

- {%include "skills.njk" %} - -

Highlighted work

- {%include "highlights.njk" %} - -

Contact

- rik@rblicht.nl / +31 6 37 27 17 91 -
\ No newline at end of file diff --git a/content/pages/index.njk b/content/pages/index.njk index d1c53c0..96357b9 100644 --- a/content/pages/index.njk +++ b/content/pages/index.njk @@ -6,37 +6,44 @@ permalink: "/"

Rik Berkelder

Lighting Designer | Software Engineer | Nerd -{%if site.site == "rblicht" %} -

About

-

- I am a freelance stage lighting technician, lighting designer, and lighting systems technician with a passion for the - intersection of technical precision and creative expression. My journey in lighting began in primary school, driven by - a fascination with how light shapes space and mood. Since 2018, I’ve been freelancing alongside a career in software - engineering and IT, transitioning to full-time freelance work in 2022. -

- -

- A perfectionist by nature, I value preparation, attention to detail, and reliability while staying flexible and - collaborative to meet the demands of live production. I strive bring professionalism, technical expertise, and a deep - commitment to elevating every production I work on, blending methodical planning with a love for creative - problem-solving and thinking on my feet when necessary. -

-{%endif%} -

Skills

-{%include "skills.njk" %} +
+ +
+ Lighting & AV +
    +
  • GrandMA2/3, Avolites, Hog4, Obsidian Onyx
    • +
  • Capture, Vectorworks
    • +
  • ATEM, Resolume, VMix, OBS
    • +
  • Timecode, Remote Production, System Integration
    • +
+
+
+ Software +
    +
  • Typescript, GraphQL
    • +
  • React (Native), Angular, NodeJS, Electron
    • +
  • Git, Docker, Gitlab CI, GitHub Actions, DroneCI
    • +
  • Sass/SCSS, Tailwind, Bootstrap
    • +
+
+

Highlighted Projects/Clients

-{%include "highlights.njk" %} +

Contact

-{% if site.site != "rblicht" %}mail@riksolo.com / {% endif %}rik@rblicht.nl +mail@riksolo.com / rik@rblicht.nl

Find me elsewhere