@tomekslesicki there was a long discussion here about Convolution reverbs and sample rates - try searching the forum.. I cant recall who it was... sorry.

@SteveRiggs said in Finalising plugins ready for release:

Hi all,

It's been a while! Hope you're all doing good.

I finally got my Apple Dev licence sorted and am ready to start finalising my first plugins ready for release.

I'm just wondering, which way around do I have to do things with the Apple dev licence, JUCE Licence and of course the HISE licence?

I don't fully know how the serial number system works for adding those into the final plugins yet, or also if there is any code that needs to be added first from JUCE and HISE licences before notarising with Apple (to get rid of splash screens etc) I'm a little stuck at the moment as to what I need to do next and in what order.

I've done some googling and looking around on the forum but not spotted anything that covers the process start to finish.

For making installers, I have packages installed already for Mac, and I have inno setup installed for Windows, but I've not made much sense of inno setup yet.

Thanks for any help or links anyway. Any pointers would be mega helpful on the order that I need to do everything in, so that I don't totally nause it up! I'll do some more research in the meantime...

(..and I almost forgot... I'm still on Xcode 8 at the moment on Mac High Sierra. I assume I need to get rid of that now and get Xcode 10? Does that even work on High Sierra and am I able to notarise using High Sierra? It's version 10.13.5)

OK so my experience:

1. You will need A HISE license, a JUCE license and an Apple Developer ID - any order.

on a Mac....(not covering AAX here..)

if you want to have a stand-alone version of your product, and if it needs an icon of its own you need to put the icon in the images folder and call it icon.png (I think that right..) - you cant add it later post compile...well you can but your codesigning wont work...

2. Compile your plug-in/stand-alone

3. codesign all your products...VSTs, AUs and Stand-alone (theres pointers on here to the KVR forum that covers it)

4. Notorize your stand-alone

5. Build your pkg

6. Noterize your package.

7. Staple your package

@pasmae said in Preset Label Update:

@Lindon How do I check with the script if a preset (the current UI state) was saved? (Still new to scripting... )
And I think that solution would only work for the moment that the preset ist saved, after a changing slider or knob value it would still hide the *, or am I wrong?

OK so - user loads a preset - so you show the preset name (lets call it "myCoolPre") in a text label

• when the user changes any control - in its call back:

• do whatever the control is supposed to do to the sound

• read the text in the label

• does this text contain a "*"?

  • if not then this is an un-modified preset - add a '*' to the front of the Name thus: "*myCoolPre"
  • if yes then this is already a modified preset - dont worry about it.

• when the user decides to save a preset

  • does the text contain a '*'?
    • if so remove the '*'
  • save the preset

@gorangrooves said in Decrease plugin initialization / load time:

@Lindon If I understand correctly, for the end-user, the experience would be identical as what I have now, but things would just be laid out differently inside the plugin back-end?

yes.

The user always presses (say) G3 to get Hi-Hat edge, and A3 to get Hi-Hat Bell, and how open or closed the hi-hat is set to depends upon a CC message (say CC 4) - so in your midi track you only ever see the articulation notes (G3 and A3) and a single CC track showing how open/closed the Hi-hat is.

In your Hi-Hat Sampler you have your Hi-Hat edge samples mapped say like this:

G4 = Hi-Hat Edge Closed
G#4 = Hi-Hat Edge 1/4 open
A4 = Hi-Hat Edge 1/2 open
A#4 = Hi-Hat Edge 3/4 open
B4 = Hi-Hat Edge open

When the Hi-Hat Sampler gets CC4 it uses the CC value to decide on the current open/closed note it should play if asked to, by looking it up in a table/array.

When the Hi-Hat sampler gets a G3 it Transposes it to the correct open/closed note to play.

Simple really - The added advantage here is that most of the players with Virtual Kits(Roland or Yamaha) we worked with at DrumDrops wanted to match the CC message to their "playing style" - so we let them edit the CC-to-open/closed table - it was a simple 127 x 127 table with marked off areas for each articulation

@Christoph-Hart said in Decrease plugin initialization / load time:

Message.setNoteNumber() - is your friend here.

Message.setTransposeAmount is your real friend if you don‘t want to handle the note off manually

pwnd again...

@gorangrooves said in Decrease plugin initialization / load time:

@Lindon I am aware that other drum samplers use a different note for each articulation. Just because others have done something in a particular way, it doesn't mean that is how it needs to be or that it is a good way to be. I find this to be a very impractical and messy way of doing this. I believe that what I designed is an improvement, an elegant, tidy, and logical solution. You could playback a groove, and use the mod wheel, set to cc4, to vary the openness of the hats. When you look at the piano roll, you don't see a mess of notes going all over the place, but just two notes with cc4 controller lane.

Err, you dont see that if you have note-2-articulation maps either. Its an internal re-mapping. I used it all the time in the DrumDrops plug-ins, where you can use a cc value to open/close the hi-hats too.

Message.setNoteNumber() - is your friend here.

But hey you may well have an elegant solution, but it seems to be an elegant solution with a loading issue. Just pointing out a way to do this that removes your problem - if its not for you then - sure please feel free to ignore what I say and work out your own solution.

@Christoph-Hart said in Step modulator ?:

That‘s a fair point but a framework for virtual instruments should make this assumption and offer both options.

Oh for sure, the more options the better I say - as long as it doesn't get in the way of the send bus FX implementation

-- no actually seriously - I see its something some people will want - but its not I think (sing out if you disagree everyone) the top of the list of things I'd like to see in HISE 3.0...nice (for some genres), sure; essential? my vote is not so much..

@lalalandsynth said in Step modulator ?:

I am a bit surprised if you dont see the value in this , like in the Serum example .

Say you have a kick on each 1/4 note and the synth is travelling through the wavetable for one bar , now if you stop and start playing on the second kick , it will start at the offset point in the wavetable sounding the same as if you would have started from the beginning. Anything else would be weird , unless you specifically wanted it to.

Yes I understand what the feature is - I just think the exact opposite is true too. I play the first note of a one-bar phrase on the first beat of the first bar... and I get one sound, I play slightly late in the second bar (like you know groove and all that) and I get a different sound...

I appreciate that certain genres of dance music have no groove at all...but the rest of the world - not so much. Which thinking about it is probably why Massive and Serum (and the like) are not so popular outside those genres

@lalalandsynth said in Step modulator ?:

@Lindon
Have you used Serum or Massive ?

I have Massive and Massive X.

@lalalandsynth so I press play on the DAW and start "noodling" on Serum - and the notes sounds different(cause they are using different parts of the wavetable) depending on where in the bar I press a note?

-- how odd, how frustrating....I can see users HATING this.