Hello HISEaholics,

I'd like to propose a simple time-saver.

A one-click option to fold all Component List panel submenus and Module Tree groups/containers.

Additionally, it would be great if they remained closed after recompilation. As of now, they reopen upon recompilation.

It could be as simple as Shift + click on a submenu arrow to close/open all of them.

Upvote if you need this as much as I do!

Cheers!

Hi,

There are many technical topics I’d like you guys to cover. However, as a musician who got into HISE primarily to develop tools for personal use—and someone still on the fence about releasing anything commercially—I’d like to propose dedicating some time to discussing the state of the audio tools business.

I understand that the main goal of these meetings is to focus on HISE’s technical aspects, and the amazing folks in the forum have been great at answering any questions I’ve had so far. But I’d be very interested in hearing you discuss the business side of things.

Looking at today’s audio tool ads, you’ll often see absurd discounts (70%-80%), even for top brands. This raises the question: is it profitable at all?

Perhaps the more experienced among us could share insights about what it’s really like. Here are some of the questions I’d ask:

• What kind of tools do you release?
• Which ones have sold well, and which haven’t?
• How many units has your top-selling product sold?
• What pitfalls would you warn against?
• I imagine most companies are one-person operations, but do you hire help occasionally?
• What other tools (besides HISE) do you rely on in your workflow to release a product?
• Which services and fees do you pay monthly or yearly to keep things running?
• What kind of copy protection do you use, if any?
• Do you release for mobile platforms?
• What DAWs do you prioritize or release for?
• What back-end servers do you use?
• What is your pricing model: one-time purchase, subscription, or something else?
• How do you advertise? Do you create your own ads or pay "content creators"?
• Which platforms have yielded the best results, and which ones have been a waste of money?

I'm looking forward to the meet.
Cheers!

@Christoph-Hart Tested it, works perfectly here! :folded_hands_light_skin_tone:

@CyberGen New findings update: Even though changing the slices setting had initially yielded positive results, it was not solving the problem 100% of the time for me. After much trial and error I found a better fix by going into the sample editor window and moving the sample end just a few cycles short from the very end. This has been giving me consistent wavetable all the way to the end.

Hope this helps. Cheers.

@d-healey This is really helpful info David. Much appreciated. Thanks.

@clevername27 Yes! Exactly. This is the kind of guidance I believe so many of us are hoping to hear during the group call. Posts like this are not often seen in the forum itself, even though these issues affect all of us who are releasing or considering releasing products. Thank you—more of this, please!

@aaronventure Oh, I see now.

"CONFIRM_PRESET_OVERWRITE=0" no semicolon at the end.
:beaming_face_with_smiling_eyes:

It works now.
Thank You.

@aaronventure trace is more for like properties, I mean something like (see below) but instead of this customized code, the original or default look and feel code. It would be so useful as a starting point reference.

//	ALERT WINDOW
 	laf.registerFunction("drawAlertWindow", function(g, obj)
		{
			Console.print(trace(obj));

			var a = obj.area;
			var mA = [a[3]*0.01, a[3]*0.01, a[2]*0.99, a[3]*0.99];
			g.setColour(Colours.darkgrey);	
		 	g.drawRect(mA, 1);
		});

@d-healey Is pretty straight forward, below an example.

David, thank you again.

I will change all my paths to stings, its going to take me a minute. I'll let you how it goes.

Cheers!

//	GLARE 1
	g.beginLayer(0);
	g.gaussianBlur(a[3]*0.04);
	g.setColour(Colours.withAlpha(Colours.white, 0.9));	
	glarePath.loadFromData(glarePathData);
	g.fillPath(glarePath, glareArea);
	g.endLayer();	

Hello,

I'm moving this from a general question into a feature request.

Kindly requesting a way to change the base octave triggered by the QWERTY keyboard into HISE. This would be very useful for when you don't have a midi keyboard at hand and need to input notes directly from the computer-keyboard. "Z" and "X" are a very popular choice for + and - one octave. I've also seen apps that use the keyboard numbers for direct octave jump.

Below the original topic.
Re: Computer Keyboard Octave

Thank you.

@DanH Unfortunately no. I requested it as a feature a some point. If I recall correctly @Christoph-Hart replied "I wouldn't hold my breath" suggesting it was not feasible. I have no idea how it works but I believe a new wavetable synth with dual oscillators would be required. Would be great to have it though. I'm still hopeful.

@T-B-Guang Having this same problem with no obvious reason. Trying this in a new tester project. only a few samples. sampler channels are the same as master channels. Have you found a solution?

@bendurso thank you for this.

Hello fellas,

This is mostly a music theory argument, so bear with me.

For a long time, I’ve noticed that the tempoSync subdivisions in HISE are not arranged in true linear order. At first glance, it might seem logical — for example, "1/8D", "1/8", "1/8T" appear to follow a descending rhythm duration: dotted is longer than standard, which is longer than triplet. That’s fine within that group.

But the problem arises when you move between groups. For instance:

"1/16D" (dotted 16th) is actually longer than "1/8T" (triplet 8th),
Yet "1/8T" appears before "1/16D" in the current list.

This breaks the musical continuity of gradually increasing rhythmic speed. It results in awkward, non-linear jumps when changing values, especially noticeable when modulating tempo-synced effects.

Suggestion:
Reorder the values based on actual timing, not just visual grouping.
For example:

  "1",
  "1/2D", "1/2", "1/4D", "1/2T", "1/4", "1/8D", "1/4T", "1/8",
  "1/16D", "1/8T", "1/16", "1/32D", "1/16T", "1/32", "1/64D", "1/32T", "1/64", "1/64T"

Now, yes — this can be worked around in scripting by rearranging arrays manually, but I figured I’d point it out in case others feel the same. It might be a worthwhile change at the source-code level to ensure smoother musical transitions and better UX and make our coding lives a bit easier.

Thoughts?

@d-healey should I add this to the gitHub issue list?

@d-healey alright, I'll give it a try. thank you.

@d-healey yes, so basically to simplify things I'm just using a knob to switch waveform that is being displayed between the two samplers. It's a bit more complex in my actual project but this should recreate the issue at a basic level.

HiseSnippet 1365.3oc6YszaaaDDdojWmH0zflfTfdo.DF8fbQfgn76VTDYKamZjHGAKmzdKXE4JoElbWhkKchZQ9O0eB4+Q+S368P6r7gHorrisZp6K4CFblcmY914Mr6HE1zf.gDYT8jQ9Tjw8vcGwUCaMjv3nC2CYbebaRfhJMiYs6HeRP.0AYXT9oZFFUV.E8y4OYWhKgaSyXgPuRvroOm4wTYb6z7YLW2CHNzSXd4t8ZMOzVvaIbEg.dJiqi7I1mRFPOhnuVIL56IACQFeMtQ+d1M5u4paYss01at11VVquUu0p2v1Y8sWc0MV0oeisHarEHzh66vTBYWEQQCPFKrqvYT2gh2viMvqXArdtTMgEpKX4X1GHbczOQ82nVCYtNcRcTAHPocxbakicaOB2l4vFyOy88YQGXlIQdGnQohvqbA3YcYvaJPxHGjVHFRO.20Vx7UYmnwymfOjCQy9DHNkGJw2EUhVB2R.2fqVwibJ8.IPLVhZaTu9iMges72VsJDqBTlmQjl6D5vD+.4LZegzyx76LS0v.ppkvyWvAhZKU7ZKo0QUF2kwol8C41JlfaJ3OiK5YoUfT3VyNU5GCFxMjtb0etZkf2vT1CMqkvoBvphMIfZV+afupTzLqDPAS6m5CNzYoGatTWhmuKUFggKJg8PBe.0oV7g8jTxo5uRsh0MzJMtIV4cUqTUaq2ANmo6Ei7OKsr1hIdoVDW2dPkRshNOPw4bqGITzWvqE4.q9tplSdT+9S8rDcAOiodrt.VdUBViG50iJyG9zWDRRKl4u30Ky2N1kj6hB9gbl5E9zD5rRWqoTmfR7oPESoDDBWUEUu74I0KEhSHlitFtXrCE8Xx2lCMoxtehx55xbnxHsbGbTzYRgO+InWd3dDEQWEm.O.x9Toho8LF6QOC5gFWSWAuGM3TkvOB+I4DHC7M9E71w.388ZNJCMG0LWRLLT.mlDqehSZuq3QB5Ga7qfBGo+32fOfYH9cY+DHFFasBzD6hcrfdkBmPWhpXCT8XljCfbqBcszcl3AL0n79yI6ptvkmaUepM8mZly0DtO.2Q2cZ53szTvqNU7uX7lLi5Sw62uO0VkA1EvG7iW4.oO5P4KigxCwcUPGOOFePRBVDdFmtY8wXOC+q8dFcjTWAwIN8L8Zuu4tgf+RVj6uzLxT63IB4ErUBxOl5SIJH7mSl6173iepTD5OoTm+jnjkSjP2avUj+fWvofeWk+M1RJBB5COmHcEj+nNgxAZeUFmiomQkAE4cTnGD64bpaftpz.X8x.pNVyraSTR1aye6HqT+DRT7FV9Jh1ZB5FSPu5DzqMA85SPuwDzalQG6PaS7iWaw1kHg1LdhKL63NWuYGfl5Pf2dtatKavXqDyoXulbWcryOBf4Vg71b+va0NY+4a7V95A2Ov5rURwXWlNTsO+LnXE3nw3Cg4g8IgtpTtEabzVvE9CEblcwRCHUev.pLO1m5CZGkBpLy37nlGScovRfYr9plOGVfkHKVwei7E27U6mZ75Kvwv0T2sy7+FCLK++9AlWkq69IiKMAqKU+CONeObTCdS873+tf5whPELmMcVGFFH1EVBvllerXI8n1X55ZZMf5R4NQD+N7SxgVoyP0GZkdHxNUUvaK46ns6MJS45QGQ6A5BSmcymRG.qZngDL2aFVWpw70klutT90kVD6PBbluoz7MktzMkZLeSo4aJMeSo4aJ8u3MktMPoGwVJdsc7eeWMVuaDG.k7n+sTUvs0zlS4uJrGLu5011EU0EDrwrJ3pypfqMqBt9rJ3FypfaNqBt0GVP85D6DpDdwMSQn1c1ONAzX+wIfkQ+AvxNeLy

@d-healey I'm not a big fan of that. I try to avoid it whenever possible. I've pretty much set everything up so that one set of components works for other in the same category, this keeps my component count manageable. Is processorId a property that must be left alone after initialization?

Hi,

As stated in the title, I'm trying to dynamically switch the processor ID on an audiowaveform. I'm scripting a very basic property change, but it's not working. It shows the change in the property window, but not in the audiowaveform tile. Can you help me figure out what I'm missing?

Thank you.

const var AudioWaveform1 = Content.getComponent("AudioWaveform1");

inline function onKnob1Control(component, value)
{
	switch (value)
	{
		case 0:
			AudioWaveform1.set("processorId", "Sampler1");
			AudioWaveform1.changed();
			break;
		
		case 1:
			AudioWaveform1.set("processorId", "Sampler2");
			AudioWaveform1.changed();
			break;
	}
};

Content.getComponent("Knob1").setControlCallback(onKnob1Control);

@DanH ok, that explains it. Thank you!