@bendurso Today I learned that right-clicking a module in edit mode shows a different context menu to right-clicking not in edit mode.

PR that adds StartPhase1 and StartPhase2 to Waveform Generator.

Coded for my own needs but someone else might find it useful.

Works great for setting a random phase offset on MIDI note-on.

Works independently for Osc1 and Osc2.

https://github.com/christophhart/HISE/pull/792

EDIT: from this conversation https://forum.hise.audio/topic/13720/free-running-or-randomised-phase-for-waveform-generator-oscillators/9

I'm fortunate that I started with a (small) audience, and I'm selling to a focussed crowd. My plugins serve a very specific niche and the producers there are always hungry for more authentic products.

I've never done any paid ads. I might do an experiment on Instagram one day. I see a lot of adverts for plugins in my feed and I'm curious how effective they are.

I sell on Gumroad. They take about 15% fee, then you pay payment processor fees. I haven't done the maths for the total cut but I'd say it's less than 20%.

It's a good deal for me because it includes basic web presence, file hosting, secure delivery, payment processing (cards, Apple Pay, Google and PayPal), email marketing and analytics.

I started selling in September 2022. I'd done a couple of free plugins before that through various platforms like SimpleGoods and SendOwl but didn't take it seriously until later.

When I started selling I posted each new product on my Facebook and Instagram accounts. The engagement was pretty good to start with but I noticed that over time, I got more results from sending emails to my ever-growing email list. When I launch a new product now, I only send it to my email list at first. Then later I post short clips to Instagram but they're supplemental to the email list.

You NEED an email list. They say "the money's in the list" and in my experience, that's 100% correct.

Free products are a great way to build your email list. Most people stay subscribed and as long as you don't flood them with emails, they're happy to receive them.

This is my email strategy:

• Launch email for every new product with 20% discount code, valid for 2 weeks
• Reminder email 48 hours before the launch discount ends
• One email per month with 20% discount off a single product, valid for 2-3 days

That's it. I don't like to bombard my list with too many emails. I'm on some Gumroad seller lists where they send continual discounts, sometimes daily. This would be way too much for me as a customer.

Gumroad includes email marketing, which is a bonus because when your list gets large things like Mailchimp, ConvertKit, etc get into the $100's/month.

I can target emails to people who have or haven't bought specific products. Very handy for offering a discount only to those who haven't bought something. Or offering a discount for a product Y to those who have already bought product X. You can also target by how much someone has spent, so you can offer extra discounts or free stuff to your most loyal customers.

Gumroad also includes extra features like affiliates (having others push your products for a % split), collaborators (where you can split a products revenue with someone else), email automations (for sending drip emails to customers - I don't use those) and upsells (recommended products at checkout).

It does have some downsides. The download links in the receipt emails sometimes don't work and you have to send a link manually to the customer (Gumroad have so far refused to acknowledge this as an issue). I also find their fees to be expensive compared to other services, but for what I get built-in I still think it's worth it for now.

Something else that might be of interest is that Gumroad recently made the source code available, so if there's a feature you want to add and you're handy with Ruby on Rails and JavaScript you might be able to contribute.

Happy to report this has been merged in to develop branch!

Some of you might remember my troubles compiling HISE on my 2020 M1 MacBook Air with 8GB RAM.

It was taking an hour to compile a debug version, if it finished at all - it usually crashed.

Seemed like the 8GB RAM limit was the issue, causing havoc with memory swap.

My solution then was to write a build script that builds my version of HISE using GitHub Actions, whenever I push a change live. It took about 15 minutes round trip to push a change, wait for the build, then download the build artefact to test the change.

I used this long-winded system to add features and fix bugs for the last few months. Painful!

Finally I upgraded to a 2024 M4 MacBook Air with 32GB RAM and I can now build debug HISE locally in 20 seconds! It's like a dream!

Just wanted to put this out there in case anyone else is having issues compiling on an 8GB MacBook.

@aaronventure said in Quick F5 tip for Mac users:

@d-healey Hold Shift while typing to amplify my anger.

Exactly this! Left pinky on the SHIFT and hammer those keys!

Same on iOS. Instead of double-tapping the shift key to lock it, I shift uppercase every character, just so it makes me more angry!

@d-healey LOOK AT THAT BEAUTIFUL RELEASE CURVE! 🥰️

@Chazrox Wouldn't you have to call SomeFunctions.HelperFunction() outside the namespace?

I use Myriad to batch process samples. It's saved me untold amount of hours in the last few years.

https://www.zynaptiq.com/myriad/

You can run individual tasks or create workflows to batch process in groups.

My usual workflow for trimming samples is something like:

1. Trim End below -70dB (tweak this based on the group of samples)
2. Fade End below -60dB (this produces a nice fade to zero at the end)
3. I also usually trim sample start below -80dB, at zero-crossing, because Logic Auto Sampler always has a bit of start gap.

You can do a lot more in Myriad (normalising to peak or LUFS, trim around loop points, set MIDI notes and velocity ranges, etc). Very handy app!

@Christoph-Hart Just came back to look at this and finally solved it!

HISE uses the system Ruby version to look for xcpretty.

If you're using a Ruby version manager like rvm, Rbenv, ASDF or chruby you'll need to switch to the system Ruby to install xcpretty.

I use chruby so I did:

$ chruby system // or however your version manager switches to system Ruby

// Confirm I'm using the system Ruby
$ ruby -v
ruby 2.6.10p210 (2022-04-12 revision 67958) [universal.arm64e-darwin23]
$ which ruby
/usr/bin/ruby

// Install xcpretty for the system Ruby
$ sudo gem install xcpretty
Password: ********
Fetching rouge-2.0.7.gem
Fetching xcpretty-0.3.0.gem
Successfully installed rouge-2.0.7
Successfully installed xcpretty-0.3.0
2 gems installed

// Run the same command that HISE runs to make sure it's there
$ gem list xcpretty
*** LOCAL GEMS ***
xcpretty (0.3.0)

@David-Healey Oh, and I still don't really know how to open multiple arbitrary script files in the code editor. I'm hoping your new course will get me thinking the HISE-way for stuff like this.

@ustk I learned git in the terminal about 15 years ago, when there weren't as many decent git UI apps around. I actually find some of the UI apps more intimidating than typing git commands directly in the terminal!

@David-Healey For me, I don't think it's things that need to be fixed - I think it's designed behaviour. Maybe it's a Mac vs Windows thing?

Some of it I can solve by updating the keyboard shortcuts, but most of it is just frustration at how text editing works.

I generally like to use the keyboard as much as I can when editing text and I find myself typing in the wrong place because the cursor isn't where I expect it to be.

And I know there's a keyboard shortcut to move a line up/down but I only ever invoke by accident and I can never find it when I want it!

I suppose there ins't really much difference between using a keyboard shortcut to focus the HISE code editor and one that switches to my own code editor. Maybe I should try that for a week and see how it goes.

@David-Healey

I edit all my scripts in HISE

I'd be happier doing that if the HISE script editor worked anything like ANY other text editor I've ever used! So many weird things throw me off all the time.

@David-Healey Yeah, it would probably just be for git. And I suppose running tests, if that ever became a thing in HISE projects. No idea how that would work though - unit tests for script functions maybe, and system tests for UI stuff

Interactive staging (-p flag) in the terminal is really easy but for merging conflicts, yeah I do use the Cursor UI.

I guess I need to get used to hopping between the two. I just feel like there's an amazing solution out there but I can't quite see it!

@David-Healey said in Move HISE project to another computer:

I have a separate backup

Yes, same here. But I know not everyone does.

Use a separate branch for each task you're working on, then merge them back to the main branch.

It's the hopping between the terminal/code editor and HISE that usually breaks this flow for me. I'm still trying to decide whether I want to edit scripts in HISE, or to do it all in a code editor, then keep hopping over to HISE to F5.

I wonder if there's any future possibility of using git within HISE, like through a full terminal in HISE. That would be dreamy.

@David-Healey Git should be the single source of truth for your project.

If you're using .hips for test patches they should really be in git, unless you discard them after use.

Doesn't matter that they're not human-readable. Git tracks binary files just fine - images, fonts, audio loops, etc. The diffs don't make a lot of sense but they don't have to for binaries.

If your laptop blows up and you've excluded .hips then they're gone forever.

That goes for your Autosave files too.

I think I'm still trying to wrap my head around the project structure when it comes to git.

Trying to commit a bunch of work, especially different tasks, is really hard to do cleanly because all of the different work mostly likely ends up mixed together in the module tree and UI XMLs.

I can see a lot of folks doing commits like "Loads of stuff"

@ustk Yeah, I do use git (use it every day for my other dev stuff). The problem was I was trying to load the XML instead of the project. Duh!

@David-Healey I am using git, but the problem was that I was trying to load the XML instead of loading the project.

So, the .hip files are completely useless? They must be if the general advice is to exclude them from git.

If so, I'm gonna remap ⌘+S to Save XML and never bother re-saving the .hip.

@David-Healey I'm asking because I had a weird situation when moving my project over.

I opened HISE, then used File > Open XML to open the main, and only, XML for the project and got a bunch of error popups, like "Error loading script interface".

What's happening there?

EDIT: just realised I have to use File > Load Project and open the project folder. Then it loads the main XML and everything is fine.