Randomiser 0.5

[very angry mobster]

Randomiser sends out a random midi CC message every time it receives a note on message.

Anyone want to test it? If so, set it up like...

(put Randomiser where Cc Seq is, Claw is where your synth or fx is connected. Blue lines, midi, brown, audio)

The Parameters
Value – The base value for the midi CC message.
Randomise – The maximum amount by which the base value is randomised.
CC Out – The CC each message is transmitted on. Randomiser should transmit cc messages on all channels.


I'm curious if this will work on other peoples systems, it works fine on mine.

Download here http://fa-audio.presetbank.net/downloads.htm

Shannon

[very angry mobster]

oh, BTW, its an VST effect. did i miss any other important details?

[FerryB]

vam,

I'm going to look at it tonight. You have use delphi right and did you use the Dib controls for the faders?

A other question I want to ask you is about your other product: CC sequencer. Does it sync against the tempo of the host?

ferry

[very angry mobster]

Yeah, Randomiser and CC sequencer have both been programmed with delphi and Randomiser uses the DIB controlls (its the first time I've used them).

CC Sequencer is designed to sync to the host tempo, as far as i know, the timing system is working now, but it's not exactly what i want.

[FerryB]

I'm on the same subject myself. That is writing Delphi Midi only VST plugins. I finished an plugin that translated the nrpn midi messages of my Peavey StudioMix midi controller into cc and note messages.

I'm asking about the sync because I'm designing a pattern stepsequencer that can be controlled by the same midi controller ala Doepfer Regelwerk. The controller has motorized faders so stepping thru the differents pattern must be really fun

Can you give me a hint on who you acomplished the midi sync in the processevent procedure?

Thanks anyway...

[very angry mobster]

i've taken two approches to tempo syncing, the first was to calculate the timing internally by counting audio samples and calulating the period of each step in samples.
steptime=(60/bpm*samplerate)/sync

the sync value changes according to the tempo division. ie. 1/1 - sync=1 1/2 - sync=2

but i don't really like this method because it needs an external trigger to correctly sync to the host.


the 2nd method uses ppqpos timing info sent from the host.

var
ptime:pvsttimeinfo;
endstep:integer; (1-16)
StepPosition:integer;

begin
ptime:=gettimeinfo(8);
StepPostition:=floor(ptime.ppqpos*sync) mod endstep;

if StepPosition<>OldStepPosition then
begin
code to be processed each step
end;

end;


StepPosition will always be between 0 - 15 for a 16 step sequence.

Using the 2nd method, the sequencer doesn't need any external triggers to correctly sync it to the host, and it will never go out of sync because of tempo changes (the first might). but it doesn't give the user as much control as the first. This method seems to work, except inside energyXT.


All the processing is done in the processAudio procedure.

is that what you were after?

[vurt]

fun in enrgy im using it in my christmas track

[stefancrs]

fun in enrgy im using it in my christmas track

toxicated?

[FerryB]

vam,

Yes, thanks for the info. This gives me a nice start to get into the matter.

ferry