@Lindon No and yes lol, the main objective is to crop the view to cover the start/end point selection and I thought that would be the simplest way if possible, because what else is it gonna display. But this looks like a good start, just gotta figure out how to calculate the zoom level and position based on that and update it automatically on changing start/end points with the AudioWaveform.
Posts made by blezzbeats
-
RE: Truncate a sample via scripting
-
RE: Truncate a sample via scripting
Having a look at this for an alternative solution:
https://forum.hise.audio/topic/5912/horizontal-zoom-for-waveform?_=1676286666131 -
RE: Truncate a sample via scripting
@Lindon Thanks, that does work fine for updating the start and end points but what I'm really looking for is if I'm able to take a sample and destructively truncate it.
So I'm guessing after this step - either remove anything before and after the start/end or copy the active range and make a new sample by passing an array of samples with only that limited range to base64 and back to a new sample map.
The reason is I want to be able to use the AudioWaveform and select a smaller range from a longer sample, and have it display exactly that range so it covers the whole component if that makes sense.
-
Truncate a sample via scripting
Is it possible to truncate a sample from the set start end end points of a samplemap via scripting?
-
RE: Saving data outside of presets
@Soundavid Thanks for pointing me to the right part of the docs I appreciate it. Always get sidetracked in there
-
RE: Saving data outside of presets
@Soundavid Sweet will look into that, can a JSON or XML file be bundled in with the plugin by default if you use include like with js scripts?
-
RE: Saving data outside of presets
@trillbilly It's a sample library and all the sounds have presets, so switching presets resets the secret panel. Hence why I need to deal with them separately.
-
Saving data outside of presets
I have a cheatcode that activates a secret panel in a plugin, and I want to save the state of it without saving it in the preset (since changing presets would reset it's state and force the user to enter the code again).
What would be the best way to do that, is there a way to store data outside of a preset?
-
RE: Problem rendering samples with modified start times
The way things are twisted together it would be much easier if there's a way to have the timer of script 1 trigger the timer of script 2 though, to avoid duplicates of like 50 variables.
-
RE: Problem rendering samples with modified start times
@d-healey The sample is divided into 16 even pieces. One timer controls when it should switch over to the next piece (next 16th), according to the host BPM, by changing the Constant modulator of the SampleStartMod of the sampler. Each time that one triggers, it triggers another timer which takes a calculation on how much to stretch the sample based on host BPM, sample rate, sample length, grain size, currently played pitch etc. and machineguns the same Constant modulator.
I had everything working pretty much, now after backtracking and rewriting everything I just need to figure out how to trigger that second timer from the first one. It may work having them run parallel?
-
RE: Problem rendering samples with modified start times
@d-healey Do you know how I can trigger the timer of the second script from the first one?
-
RE: Problem rendering samples with modified start times
I think I found the problem in case anyone else runs into it. If you create a timer with Engine.createTimerObject(), it will be straight-up ignored when you render it in your DAW. The regular onTimer function does work though. I used a timer to trigger another timer so I guess I'm outta luck.
-
RE: Problem rendering samples with modified start times
@d-healey One follow-up question that I can't seem to find any good info on when I'm detangling my scripts, how do I update a variable in another script from the interface script?
-
RE: Problem rendering samples with modified start times
@d-healey Thanks for your input!
-
RE: Problem rendering samples with modified start times
@d-healey Oh yeah? I got that backwards then. I thought deferring callbacks was useful for non-realtime things.
You think that might have something to do with the audio being rendered differently too?
-
RE: Problem rendering samples with modified start times
@d-healey Didn't know there was a way to do that with an envelope, my project calculates the bpm based on the sample length, chops a sample up into pieces, and plays it back in different sequences in the tempo of the host bpm regardless of pitch. So it's a haxxor timestretch using the sampleStartMod that needs to be as precise as possible. Surely some sort of timer must be needed?
-
RE: Problem rendering samples with modified start times
@d-healey Any clue why this happens?
-
RE: Problem rendering samples with modified start times
Increase the timer speed on onNoteOn() for a more dramatic difference, in my real project I have it pushing down at 25.