What are the functions I should look at for doing an arpeggiator?

[Christoph Hart]

Oops, you're right - Actually I haven't used the getNumSetValues() function since ages. It's fixed now.

But I actually don't understand why you create a MidiList in the onNoteOn callback without referencing it, but as David suggested, this is a bad idea anyway as it allocates.

Now to your actual problem: the most simple solution is using a plain old array for this. I added a method that reserves storage so you can insert elements without allocating.

You can then use the sort method to change the arp order.

const var notes = [];

// This is new: 
notes.reserve(127);

function onNoteOn()
{
	notes.push(Message.getNoteNumber());
}
function onNoteOff()
{
	notes.remove(Message.getNoteNumber());	
}
function onController()
{
	
}
function onTimer()
{
	
}
function onControl(number, value)
{
	
}

BTW, If you press the debug button, you can see the content of the array in the live variable watch and check that it works.

[elanhickler]

Ok thanks!

I got it built, but uhh... Is there a "get num elements" function for array?

[Christoph Hart]

https://www.w3schools.com/jsref/jsref_length_array.asp

[elanhickler]

Ok, so the timer has some limtations. I will have to schedule midi notes to be played to overcome the speed limit, but not sure how much time I should use for a "block". What is your suggestion?

[Christoph Hart]

What limitations have you encountered? Do you mean the "Go easy on the timer" speed limit?

[elanhickler]

Yes that

[elanhickler]

How should I address the timer limitation? What constant timer should I use to schedule faster midi sequences?

[Christoph Hart]

How fast do you need the timer to be? This is a pretty random value that is only there for safety reasons (so you don't freeze the CPU by eg. Synth.startTimer(0). I didn't need it to be any faster until now, but it's only a number in the code not an actual limitation.

[elanhickler]

How far can we push it? I don't want the end user to complain that the arpeggiator isn't running fast enough. What about 10ms? What about 1ms? 5ms?

[Christoph Hart]

Anything below 20ms would make sense IMHO (at this speed, you won't be able to tell either note pitch or note length).

[elanhickler]

Ok let's go with 20ms for now. If a user complains I'll let you know.

[elanhickler]

how do you get the current global tempo of the DAW?

[Christoph Hart]

Engine.getHostBpm()

[elanhickler]

How do you create a table for the steps? I need the bar graph type slider. I looked at the widgets, couldn't figure it out.

[d.healey]

I think what you're after is the sliderPack widget

[elanhickler]

With the example script Christoph posted, note off does not work. Setting sustain to 0db (all the way up) will have the synth playing the note indefinitely... unless the AHDSR is not implemented correctly.

[Christoph Hart]

Yeah that was just a proof of concept thingie. note offs have to be taken care of explicitely.

[elanhickler]

why is it that when you do Synth.startTimer(value) it doesn't trigger the onTimer call back until the interval? I need the timer callback to be triggered right away.

[d.healey]

What I did for this was put the functionality I needed in the onTimer callback into a function, I then was able to call this function before I started the timer and then afterwards it is called by the timer

[Christoph Hart]

Yes this is the best way.

It's common practice that the first timer execution is delayed. Otherwise you couldn't call Synth.startTimer from the onTimer callback without nasty hacks to prevent endless recursion.