The Wiggler is really cool. Very limited, sure, but the expressiveness is great for a DIY project.

https://www.youtube.com/watch?v=x4khM5Bjihg

https://soundwork.shop/wiggler-1

@griffinboy said in Midi Player :

@Robert-Puza

One of my frustrations with midi keyboards is that they generally only detect the velocity at which a note is initially pressed.
I wish more keyboards had continuous velocity control.

Do you mean aftertouch?

Many MIDI controllers/keyboards have this feature.

It's mostly channel (monophonic) aftertouch but some have polyphonic aftertouch.

@VirtualVirgin I think you need to load the image(s) into the pool first.

https://docs.hise.dev/scripting/scripting-api/engine/index.html#loadimageintopool

Engine.loadImageIntoPool( String id)

@Morphoice For the effort you'd need to style the built in preset browser you may as well build it yourself.

I'm in a similar situation and just starting to build my own.

Would be good if there was a snippet for a simple preset browser. Shows a single list view of the available presets, No user save functionality. Just loading existing presets.

If I make anything that I'm remotely proud of I'll add it.

Check out the Cleveland Music Hothouse DPS pedal project.

It's based on Daisy Seed and the physical pedal has the Chase Bliss style layout of 6 pots, 3 multi-way switches and 2 footswitches.

Anything that can run on a Daisy Seed can run in this pedal. The best part is, all the stereo audio I/O boards are already there so it's a really easy build.

https://clevelandmusicco.com/hothouse-diy-digital-signal-processing-platform-kit/

I've got a kit sitting here next to me waiting to be built.

@bendurso For that price it's tempting to get the new M4 Mac mini just for compiling HISE and running Parallels for Windows exports.

@d-healey @Dan-Korneff @Oli-Ullmann Sorry, I was thinking about Maize Sampler

When you export at double size make sure the image name ends with @2x so HISE can recognize the format.

Like this: "background @2x.png"

EDIT: I don't think this is actually a thing in HISE. I was thinking about another app.

@mmprod said in scrolling audio display/visualizer:

By any chance, can I style things other than color as well?

Like what? There's not much else to customize.

You can already set the width and height, the colours used to draw the waveform, including the stroke width of the outline, and the colour of the background. By setting the buffer size you are also setting the scroll speed.

In my plugin the audio is mono so I display only one channel of the waveform by putting the floating tile in a panel and making it twice the height. The bottom half is cut off by the panel bounds.

@mmprod said in scrolling audio display/visualizer:

@Lindon Also, can I zoom out even more? Like more than 32768 samples

Synth.getEffect("Analyser1").setAttribute(1, 65536);

This is double the 32768 available in the dropdown, and therefore half the speed of scrolling, and seems to be the maximum allowed. Settings higher than this are ignored.

The '1' refers to the BufferSize attribute.

@mmprod said in scrolling audio display/visualizer:

Is it style-able any further?

Use a LookAndFeel script

const laf = Content.createLocalLookAndFeel();

laf.registerFunction("drawAnalyserBackground", function(g, obj)
{
	//fill the background
        g.fillAll(Colours.blue);
});

laf.registerFunction("drawAnalyserPath", function(g, obj)
{
	// draw the outline path
        g.setColour(Colours.red);
	g.fillPath(obj.path, obj.area);
	// fill the path
        g.setColour(Colours.red);
	g.drawPath(obj.path, obj.area, 1);
});

Content.getComponent("Analyser1").setLocalLookAndFeel(laf);

@Christoph-Hart Excellent!

Is there any reasonable way I could've discovered that on my own through documentation?

Or is it a 'click around and see' kind of thing?

@aaronventure An autoscroll toggle would be cool for the console.

Is it possible to load a MIDI file into the HSIE transport when loading a preset?

I usually keep a MIDI file running while I'm tweaking things but I have to load it every time I open the preset in HISE.

Is there any way to load it automatically?

@d-healey said in Issue compiling HISE on Mac:

@bendurso said in Issue compiling HISE on Mac:

Debug is not slower than release?

Debug will build faster because it doesn't have to optimize as it does for the release.

Compiling a Release build is actually quicker for me than compiling Debug.

In Safe Mode (I can't realistically compile in normal mode):

• Debug takes ~13 mins
• Release takes ~10 mins

The Release app is much smaller too, 44MB compared to 195MB for Debug - is this normal?

EDIT - just tried building Release on GitHub and it was indeed slower - 23 mins compared to 11 mins for Debug.

@Lindon I find deleting the build (not Builds!) folder usually fixes this. Then I'll get the proper timestamps on both Debug/HISE Debug.app and Release/HISE.app

Projects > standalone > Builds > MacOSX > builds (delete this folder)

Also, sometimes Xcode builds HISE and the app size is around 100KB so I assume it failed but when I double click the HISE app it opens properly. Very strange.

@Christoph-Hart Cools

@DabDab Could you post a simple snippet that shows the issue please? Something I can use while I'm fixing the problem. Thanks!

@bendurso said in Issue compiling HISE on Mac:

@dannytaurus Did you disable x86_64 from "Valid Architectures" on Projucer?

I just was compiling Hise and forgot to remove that option, so it ended up running for about 20 minutes before giving me an faust error. Once I removed the option, it compiled in just 4 minutes. The process uses nearly all the RAM (7GB), but it's still fast.

Thanks for the suggestion.

I think my problem is related to other things running on my MacBook. When I compile is Safe Mode it only takes 13 mins, which is fine by me. I would like to get it down to 4/5 mins but 13 mins is OK.

However, I checked Projucer and the x86_64 was indeed checked - but unchecking it doesn't seem to make any difference here.

In Safe Mode it still took 13 mins to compile and in regular mode I let the build run for 30 mins before I cancelled it.

Since I'm building in Xcode for 'My Mac' (Apple Silicon) I think maybe the x86_64 in the Valid Architectures list doesn't get used.

@d-healey said in Compiling HISE with GitHub Actions:

Try 6 or 4 - this will free up RAM which might help, but using fewer threads might negate the gains.

Yes, will do. I'm trying compiling with the script first, since you can't set jobs in the Xcode UI anyway.

First I'll see how the script build compares to the Xcode UI build. Should be the same I'm guessing.

Then I'll reduce the threads in the script to see what effect that has.