Anders, 39, from Malmö, Sweden. Sample lib dev, mixing engineer, aspiring Hise developer, web-ui development & design, all-round tech-tinkerer and relapse skateboarder. Unnecessary stickler for detail. :/

I made a tool for myself a while ago, a translator for SFZ to HISE samplemaps that worked better than the internal one in HISE did at the time. Since then @Christoph-Hart fixed the importer and it now works better. Even so, I went ahead and made it an open source web app (standard JS) that translates SFZ into HISE samplemaps.

It also does another thing I wanted at the time I started the project and that came from another thing I was doing, which is to gather up all the opcodes into an object form so I could interface and re-work it a bit and save it as data. So this app outputs a JSON object that you can copy to clipboard with a button on the app ui to raw JSON or in a variable form. So either just the object itself { data } or in a var x = { data };.

The project is now on my website, KeyPleezer.com, and you can check it out and test it out and see if it works for you. It can be used for those SFZ instruments that are in structures that HISE has issues with or where settings in the SFZ to HISE converter app can help solve the issue and get you a valid samplemap.

The fact that you get an object with the opcodes makes it possible to output other formats as well, like the DecentSampler.

I will be publishing the source and a stand-alone HTML/JS app on Github soon and then post the links here.

Until then you can test it out in the published web tool:

https://keypleezer.com/sfz-to-hise-converter/

I wrote a little manual for it as well:

https://keypleezer.com/sfz-to-hise-converter/manual/

I'm sure there are bugs remaining in it so feel free to help me test it out and find them, give feedback on features etc.

Added a link to the app to the SFZ format site, now the SFZ to HISE converter is linked (and thereby HISE itself :) ) from the tools section:

https://sfzformat.com/software/tools/

The open source project is accessible here on GitHub:

https://github.com/anderseklov/SFZ-to-HISE-converter

I still did not add a release yet, but will soon. Then you can download a minimalistic HTML app and keep in your book marks, work with offline etc. Or just use the live web app.

@d-healey Very nice page, will check it out in detail. But this is new to me:

const var foo = a || b;
const var bar = !c;

Very efficient.

Very well made plugin, looks great!

@d-healey said in Cant build with IPP, but I could the last 2 yrs.:

@andioak IPP isn't included with HISE.

Dough! Haha, no it isn´t included, you're right. IPP is just implied as a somewhat good performance enhancement addition.

Okay, I found few examples of (to me less understandable) comparisons of IPP vs FFT3W, but this one of the KissFFT and FFTW3 has some single-precision bumps of around 2-7x the speed:

http://www.fftw.org/speed/CoreDuo-3.0GHz-icc64/

I just read that the GNU GPL contains some kind of linking exception. So perhaps that can apply to using the IPP with a GNU GPL plugin.

I would worry about the opposite order here, the IPP license's reservations to be delivered within the GNU GPL. But of course, GPL-v3 is nasty in its allowances of differences in open:ness, so perhaps your worry is more warranted.

Still I would avoid including any proprietary components in a free software app.

I agree entirely.

@lalalandsynth said in Creating dynamic fx's with Drag and Drop functionality in javascript?:

Ok, as for the ids , I was thinking of having say 4 fx available per slot , then just switch which one is loaded , obviously i would need to think of having the sliders and buttons
copied between them.

I know this one is quite old, but still relevant! :)

Perhaps it is more efficient having an object store all latest values with each knob twist or button on-off action. Then loading the new set of configured plugins into place followed by initiating the values of the current states object. The states retrieved into the plugin structure will be the latest recorded for each UI elements.

Not sure all plugin states or knobs can actually be stored. I mean, it can be stored ahead of time in data inside the HISE design application, the one we use to design a plugin, but to be entered into the same strings or structures in a finalized plugin? Hopefully.

Example (calling JS/HISE object "currentstates"):

• initiate plugin, currentstates.plugins.plugin-in-question.control-name stores initial values if not loaded from a preset.
• twisting the knob of the plugin-in-question updates the value in currentstates.plugins.plugin-in-question.control-name
• reordering using the drag-and-drop re-initiates the reading of the object based on released state

This approach is common in web dev and the tech stack item is called Redux.

I guess that part could be seen as pretty obvious but still, if the saving of all of a plugin's states can be done easily, the approach is simple. Perhaps the even easier thing would be to run the UI elements's UI callbacks on re-initiation.

Is it possible to run a callback from script? Or is that just possible with actual user input?

(there is also a way to just run a function that does the same, extracting the actual actions from the designated callback function, which would do the same)

@d-healey Okay, but the icons should be a .icns file, a multi-png icon file with all resolutions. Made with this script: (iconutil)

# shell script for creating an icon for an application from a set of input images

input_filepath="icon_name_1024_x_1024.png"
output_iconset_name="outputicon.iconset"
mkdir $output_iconset_name

sips -z 16 16     $input_filepath --out "${output_iconset_name}/icon_16x16.png"
sips -z 32 32     $input_filepath --out "${output_iconset_name}/icon_16x16@2x.png"
sips -z 32 32     $input_filepath --out "${output_iconset_name}/icon_32x32.png"
sips -z 64 64     $input_filepath --out "${output_iconset_name}/icon_32x32@2x.png"
sips -z 128 128   $input_filepath --out "${output_iconset_name}/icon_128x128.png"
sips -z 256 256   $input_filepath --out "${output_iconset_name}/icon_128x128@2x.png"
sips -z 256 256   $input_filepath --out "${output_iconset_name}/icon_256x256.png"
sips -z 512 512   $input_filepath --out "${output_iconset_name}/icon_256x256@2x.png"
sips -z 512 512   $input_filepath --out "${output_iconset_name}/icon_512x512.png"

iconutil -c icns $output_iconset_name

rm -R $output_iconset_name

I mean if one is to be a good boy and future-proof the icons on mac with all the resolutions (retina, 4k, 5k, 8k etc)

So can I just use a icon.icns instead?
@Christoph-Hart

A large png file is sometimes not that pretty once it is downsized, can be blurry.

@DimitrisSP @Natanr @yall

Thanks a lot @DimitrisSP for the vu-meter. I modified it a bit to make whole integers from your png of 107 strips and set it to -100 to +6 dbFS. Also added peak values in labels for both L, R and highest of the two.

Here is that project (scriptnode 2020-08-20): LevelMeterTest--andioak-peak-values.zip

@Christoph-Hart Is there a pan-law compensation built into the Simple Gain module/plugin? To compensate for the increased value from the other channel? The values I get are steep when I pan towards one way, but it might be my programming here. (and my gain is +1, but at Left 40:ish i get around 5-6 db over the center peak, that´s about what pan law should compensate for...) (and the gif below is 7fps :) )

Here it is:

Script of this thing:

Content.makeFrontInterface(600, 500);

const var LevelMeterL = Content.getComponent("LevelMeterL");
const var LevelMeterR = Content.getComponent("LevelMeterR");
const var LevelMeterLock = Content.getComponent("LevelMeterLock");

// show values as well, via label with whole integer db values.
const var Label_MeterValue = Content.getComponent("Label_MeterValue"); // the peak of the strongest channel. 
const var Label_MeterValue_L = Content.getComponent("Label_MeterValue_L");
const var Label_MeterValue_R = Content.getComponent("Label_MeterValue_R");



// ------------

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

const var SimpleGain1 = Synth.getEffect("SimpleGain1");

//Decay Rate
const var DECAY_RATE = 0.93;

//Current Values
var curLevelL = 0.0;
var curLevelR = 0.0;
var curLevelM = 0.0;

//Timer Callback
const var t = Engine.createTimerObject();

t.setTimerCallback(function()
{
//Synth Values
  var LevelL = SimpleGain1.getCurrentLevel(1);  
  var LevelR = SimpleGain1.getCurrentLevel(0);
  
//Peak Synth Values  
  var peakLevelL = Math.max(LevelL, LevelL);  
  var peakLevelR = Math.max(LevelR, LevelR);
  
  var peakLevelMax = Math.max(LevelL, LevelR);

//Kick Left  
//-----------------------------------------------------------------------------  
  if (peakLevelL > curLevelL)
    {
      curLevelL = peakLevelL;
    }
  else
    {
      curLevelL *= DECAY_RATE;
    }

//Kick Right  
//-----------------------------------------------------------------------------     
  if (peakLevelR > curLevelR)
    {
      curLevelR = peakLevelR;
    }
  else
    {
      curLevelR *= DECAY_RATE;
    }
    
//Kick Max peak for mono out or label with max peak for strongest channel.
//-----------------------------------------------------------------------------     
  if (peakLevelMax > curLevelM)
    {
      curLevelM = peakLevelMax;
    }
  else
    {
      curLevelM *= DECAY_RATE;
    }

  
//Decibel Conversion  
//-----------------------------------------------------------------------------   
  LevelL = Engine.getDecibelsForGainFactor(curLevelL);  
  LevelR = Engine.getDecibelsForGainFactor(curLevelR);
  var LevelMax = Engine.getDecibelsForGainFactor(curLevelM);
  
//Set Values  
//----------------------------------------------------------------------------
  LevelMeterL.setValue(LevelL);  
  LevelMeterR.setValue(LevelR);
  
  Label_MeterValue.set("text", (LevelMax >= -99) ? Math.round(LevelMax) : -100); // use Math.round (round up) for all except minimum value, -100. 
  Label_MeterValue_L.set("text", (LevelL >= -99) ? Math.round(LevelL) : -100);
  Label_MeterValue_R.set("text", (LevelR >= -99) ? Math.round(LevelR) : -100); 
  
});

t.startTimer(30);

UPDATE: this code does what it´s supposed to, but using labels to be updated by a timer seems to crash hise and the output plugins/standalone exported instruments. Read here about it.

Added a link to the app to the SFZ format site, now the SFZ to HISE converter is linked (and thereby HISE itself :) ) from the tools section:

https://sfzformat.com/software/tools/

This should be pretty easy to test out. One developer ID with 2 separate plugin codes. A few testers on different DAWs and machines with different OS versions.

I can be a tester on anyone's plugins. Do not, however, have a project ready or a functioning HISE install, cause of a re-installation issue at the moment...

Very well made plugin, looks great!

@RastaChess The output plugin needs to have your midi-keyboard activated through the tile on your plugin settings page (which I assume you have) to receive midi, as David mentioned. Also you need to add a midi panel for the midi-channels too.

The open source project is accessible here on GitHub:

https://github.com/anderseklov/SFZ-to-HISE-converter

I still did not add a release yet, but will soon. Then you can download a minimalistic HTML app and keep in your book marks, work with offline etc. Or just use the live web app.

I made a tool for myself a while ago, a translator for SFZ to HISE samplemaps that worked better than the internal one in HISE did at the time. Since then @Christoph-Hart fixed the importer and it now works better. Even so, I went ahead and made it an open source web app (standard JS) that translates SFZ into HISE samplemaps.

It also does another thing I wanted at the time I started the project and that came from another thing I was doing, which is to gather up all the opcodes into an object form so I could interface and re-work it a bit and save it as data. So this app outputs a JSON object that you can copy to clipboard with a button on the app ui to raw JSON or in a variable form. So either just the object itself { data } or in a var x = { data };.

The project is now on my website, KeyPleezer.com, and you can check it out and test it out and see if it works for you. It can be used for those SFZ instruments that are in structures that HISE has issues with or where settings in the SFZ to HISE converter app can help solve the issue and get you a valid samplemap.

The fact that you get an object with the opcodes makes it possible to output other formats as well, like the DecentSampler.

I will be publishing the source and a stand-alone HTML/JS app on Github soon and then post the links here.

Until then you can test it out in the published web tool:

https://keypleezer.com/sfz-to-hise-converter/

I wrote a little manual for it as well:

https://keypleezer.com/sfz-to-hise-converter/manual/

I'm sure there are bugs remaining in it so feel free to help me test it out and find them, give feedback on features etc.

@d-healey said in Time Stretching:

I think for now this is beyond my C++ level. I'll come back to it again at some point unless someone else implements it first (pleeeeaaaassseeee!!!) :D

Thanks for giving this a go, David! This is indeed an attractive feature for hise! Can't wait for this to work. My C++ is much worse than yours, but perhaps not this guys:

The Audio Programmer - "Implementing a TimeStretching Library (RubberBand)":

https://youtu.be/XhmM8HZj7aU?t=1721

(It's a live stream, so watch in 1.5x speed :) , not sure it gives you more insight than you got cause it's for JUCE. Perhaps the Hise part is more difficult)

@Christoph-Hart Okay, I see. Too bad but I see the time-sucking black hole in re-inventing the wheel for you, especially for such a unique computing environment. Already lots of time spend making new features and fixing bugs. Not worth it.

@Christoph-Hart Thanks for the clarification!

The CPUs instruction set for SIMD seems to be a big factor for the actual gains. I found a nice thesis by a guy named Anthony Blake called "Computing the fast Fourier transform on SIMD microprocessors", including lots of comparisons from quite recent machines (i7-2600, around 7yrs old "only":=). It included a high-performance FFT library called SFFT / Spiral, vDSP, Intel IPP and FFW3: (page 140 in pdf)

https://www.cs.waikato.ac.nz/~ihw/PhD_theses/Anthony_Blake.pdf

According to the benchmarks, another library called SFFT (Sparse Fast Fourier Transform) was used that partially trashed the others (FFW3/vDSP/IPP) around the 4-64 bit sets in lots of tests. But according to the Spiral SFFT page:

the algorithm can be faster than modern FFT libraries. However, the reference implementation is not optimized for modern hardware features such as the cache hierarchy, vector instruction sets, or multithreading.

Too bad, would have loved to stare at some more graphs and then going "I wish I understood the context". :) It is now being used in 3D FFT to analyze the trajectories of gravitational pulls or ... well space n shit

@d-healey Thanks for the video, I saw it yesterday and it is really good. He explains it perfectly.

Hi, I'm new to algorithms and C++ and all the tough stuff. I saw a few videos on FFT (Fast Fourier Transform) and the basics of shortening down lots of big iterations, especially for waveform based calculations and deductions. Still, it's a bit fuzzy.

My main question is:

• If an FFT library (such as IPP or FFTW3) is used, is the end code binary (hise executable or your end-software/plugin executable) going to run faster? Or is it just the compilation time that is reduced via the FFT algorithms?

• • aka, does my plugin run faster during it's use if I use IPP/FFTW3 during compilation of it?