@JulesV You want the clicked button to become wider by some amount, and the buttons to the right of it to shift along by the same amount?

I would store the x of button one and your required width of btn_off and bin_on in variables.

Then in the button callback, set the position and widths of all the buttons with something like:

PageButtons[i].set("x", x);
PageButtons[i].set("width", w);

where you increment x in the loop by the width of the drawn buttons, and w is set based on the clicked button.

@JamesC Do you think it was a bug, or user error?

If you can reproduce it in a minimal project and post a snippet, we could look into it further.

@David-Healey Yeah, I don't ever see myself doing that amount of automation. It feels too forced and contrived to me.

I've tried it before with different products (non-music related) and I ended up spending more time endlessly tweaking campaigns than actually making the product better.

My strategy over the last 3 years has been quite sparse:

Products: one launch email with a time-limited discount code, then one reminder email 2-3 days before the code ends.

Marketing: maximum one email per month with a product-specific discount code, only sent to those that don't own the product.

On top of that I've sent out a couple of cross-sell discount codes ("Since you own Product X you might like 20% off Product Y") and a DAW survey.

I do have it on my list to send out a post-purchase email, something like "Hope you enjoy Product X, here's a 20% discount code for your next purchase". It's easy to set up in Gumroad, just haven't got around to it yet. It would be very easy to measure the performance too. That's more like the kind of thing you posted above.

EDIT: just read through this again and I think I'm actually just very lazy!

@David-Healey It's got some nice features like campaigns, webhooks, autoresponders, etc. But like I say, I haven't dug into it yet. I bought the license on a deal, more out of curiosity.

Newsletters is basically just marketing emails under a slightly nicer name.

Autoresponders
Automate your marketing by setting up a series of emails in drip campaigns to automatically follow up with your subscribers at time intervals you set. Or send emails annually or one off emails at a specific date. Keep your subscribers engaged and your brand at the top of their mind.

Rules & Webhooks
Decide what happens when something happens - by creating 'Rules'. For example, setup a rule to get notified by email when a scheduled campaign starts sending, trigger a webhook when an autoresponder is sent, unsubscribe someone from a list when they're signed up to another, and so on.

Custom fields
Create custom fields to store more than just 'name' and 'email'. Not only can you store more information about your subscribers, you can use them for list segmentation or personalization tags in your newsletters for a more personalized experience.

@Lindon I should also clarify that I run ads too. I do £40/day in one campaign with 4 ads, all on Instagram.

I haven't emailed my list since November last year, and the last email before that was August. So the consistent revenue I'm getting now is mostly ad-based rather than mailing list-based.

However, I still swear by the mailing and will be working to build it up more this year.

@Lindon You could also look at Sendy. I bought a license a while ago but not got around to setting it up yet.

It's a one-time $69 fee and you self-host it, so another few dollars a month for a small shared server.

It sends using SES at $1 per 10,000 emails.

https://sendy.co

@Lindon For our level of usage, SES pricing is basically negligible. From their examples, 250,000 emails per month is about $25/mo.

It's only really when you get into sending millions of emails per month, and/or sending very large emails, that price starts to become a factor.

Since I use Gumroad, sending emails to my list is included in their revenue cut. I can essentially send as many emails as I like and pay no more for it than the usual cut.

Having said that, this year I'll be looking to move away from Gumroad to selling direct on my own website, so I'm interested to see how this conversation goes.

@David-Healey Another quirk, at least on Mac, is that CMD+D is assigned to both ScritpNode > Duplicate Node and Interface Designer > Duplicate selection at cursor.

This works fine within HISE because of the different contexts, but if you assign a different shortcut to either action, then try to assign the default back again, it will remove the other one.

So I suppose the issue is that duplicate shortcuts already exist in HSIE, but the user isn't allowed to assign duplicates themselves. Which is a little confusing.

EDIT: probably not worth the time to attend to either

@David-Healey And it fixes the second issue where storing CTRL+D as a shortcut in the XML didn't persist between relaunches - because this is expected HISE behaviour when it meets a default shortcut?

@Lurch All you need is in David's first post in this thread: https://forum.hise.audio/topic/14184/juce-submodule-psa?page=1

@Lurch Do you know JUCE was recently moved to a git submodule? You shouldn't need to drop JUCE in yourself.

The version of JUCE used in HISE is customised by Christoph. If you dropped in the regular JUCE that might be the cause?

@xxx The Projucer file you need to open is in projects > standalone > Builds > HISE Standalone.jucer

After you've opened that once, and saved it to create the Xcode project, you don't need to open it again to rebuild HISE. You can just launch Xcode and open the recent Xcode from there, and build.

The only time I open the Projucer file is to add/remove preprocessors. Which is rarely.

@Christoph-Hart Wait.. does that actually work? I thought we had to do that manually?

We're talking about plugin builds, right - not HISE builds?

@David-Healey said in Settings Window Bugs:

what about the team ID? I don't think that's used.

Looks like only in the redundant iOS code, but Christoph would know best on that. Just in case it messes with Mac exports.

@David-Healey said in Settings Window Bugs:

MIDI channel is stored in GeneralSettings.xml, not DeviceSettings.xml

Seems odd.

It's been there for 9 years, so I guess it's just where it started out.

Here's the PR: https://github.com/christophhart/HISE/pull/850

@xxx FWIW Xcode 26.1.1 works fine for me, but I'm on Sequoia 15.7.3, not Tahoe.

@David-Healey

Should we remove the Extra Definitions IOS field entirely? Same for App Group ID?

Just for kicks, should we update the (c)2017 default in Company Copyright to the current year?

Should Visual Studio Version be updated to 2022 if it's the new default?

The tooltip icon for the MIDI Device still shows when there's no MIDI Device connected, nor field visible.

Tooltips:

Tweak the Embed Image Files tooltip to mention image files instead of audio files.

Extra Definitions has empty Examples section, either add examples or remove the header.

We should probably update the tooltip on VST3 Support now that it's standard.

Enable Callstack has a broken Examples section.

@David-Healey said in Settings Window Bugs:

Selected MIDI channel isn't restored - all channels are enabled on each start. I also don't see the channel in DeviceSettings.xml

That's because it isn't saved to the XML. I've got a fix for it, just need to make a PR

EDIT: for clarity, MIDI channel is stored in GeneralSettings.xml, not DeviceSettings.xml but the code is missing to update it when you update in Settings. My PR should fix that issue.

@xxx HISE 4.1.0 sounds like you might be using the downloaded release from GitHub.

Did you build HISE from the source code? If so, which branch and which commit?

Posting this in case it helps anyone else. I just banged my head against a brick wall for too long before I realised how simple this was!

When using a Floating Tile with content type Waveform (to display the waveform of Sine Wave Generator or Waveform Generator, for example) the default waveform path is a filled shape.

You can override this with LAF function drawAnalyserPath and draw a line path instead of a filled path:

laf.registerFunction("drawAnalyserPath", function(g, obj)
{
	g.setColour(Colours.white);
	g.drawPath(obj.path, obj.area, 5);
});

However, this means that the path is clipped at the bounds of the floating tile, especially at wider line thicknesses:

To prevent the clipping, I fudged around with it for longer than I want to admit before I realised the answer is to simply reduce the area that the path is drawn in, by half the thickness of the path:

laf.registerFunction("drawAnalyserPath", function(g, obj)
{
	g.setColour(Colours.white);
	g.drawPath(obj.path, obj.area.reduced(2.5), 5);
});

Voila! No more clipped paths! Top row is using obj.area, bottom row is using area reduced by half line thickness:

You might want the left/right of the path to bleed out of bounds, in which case change the reduction from all-round to y-only:

obj.area.reduced(5) 👈 all-round
obj.area.reduced(0, 5) 👈 y-only

Note: you might need to compile with HISE_USE_SCRIPT_RECTANGLE_OBJECT=1 for the reduced and other Rectangle helper functions, as per the docs: https://docs.hise.dev/scripting/scripting-api/rectangle/index.html. Not sure if it's still the same, or if it's built-in to all new builds.