Missing values on script output

GDLive · Unread post by **GDLive** » 04 Mar 2015, 16:53

Hello,

I've tried to write a basic and little script to gives intermediates integer while input has changed with a step (0-10 for example).

[c]/ parameters declaration
var dataIn, dataOutContinious : Tparameter;
var current : single;
var i : single;

// initialisation : create parameters
procedure init;
begin
dataIn := CreateParam('dataIn',ptDataField);
SetIsOutput(dataIn,false);
dataOutContinious:= CreateParam('dataOutContinious',ptDataField);
SetIsInput(dataOutContinious,false);
SetValue(dataOutContinious,0);
current := dataIn;
//SetFastCallBack( 1, false);
end;

// Callback procedure
Procedure Callback(N:integer);
begin
current := getvalue(dataIn);
i:=getvalue(dataOutContinious);
while abs(current-i)>1 do
begin
i:=i+(current-i)/(abs(current-i));
SetValue (dataOutContinious,i);
ftrace(getvalue(dataOutContinious)); // OK, all intermediate values !!

end;
setvalue (dataOutContinious,current);
end;

// Global variables
//////////////////////////////
// main proc
//////////////////////////////
Procedure Process;
begin
end; [/c]

When I plug a counter or a data out on the dataOutContinious output of the script, I miss intermediate values.
What am I doing wrong ?
=> Does the Callback procedure allows only one output change ?
=> Is it a speed pb ?

Thanks for your advise,

patch here : http://www.sensomusic.com/forums/uploads.php?file=MissigValuesScript.pat

GDLive

sephult · Unread post by **sephult** » 04 Mar 2015, 17:14

Hmm, dopey me I see that you commented the callback speed out. Therefore it should default to TRUE.

I see that you haven't defined any SetMin or SetMax values. What is the range of values for data you are trying to output.
Sometimes I forget to set these (just did like 2 minutes ago in my script) and find myself not getting the data out that I want.

GDLive · Unread post by **GDLive** » 04 Mar 2015, 17:29

No change with setmin setmax & setfastcallback false or true

sephult · Unread post by **sephult** » 04 Mar 2015, 17:30

I don't completely understand what the intent is, however I found it curious how you hooked up the counter.
It seems the counter never counts because you keep resetting it from the source oscillator.

As far as intermediate values, can you describe more about. So basically your script is just looking like a pass-through for the oscillator source.
Are you trying to create the in-between integers, between -10 and 10?

I guess I am not understanding fully.

GDLive · Unread post by **GDLive** » 04 Mar 2015, 17:44

Are you trying to create the in-between integers, between -10 and 10?

Yes ! (and with the [c]ftrace(getvalue(dataOutContinious));[/c], I see that it's working) :/

GDLive · Unread post by **GDLive** » 04 Mar 2015, 17:50

(we could forget the reset of the counter, I wanted to count the has changed values to be sure not to miss some intermediates values)

sephult · Unread post by **sephult** » 04 Mar 2015, 17:51

So I am not 100% sure how to fix, still looking at the moment.

It looks like you are triggering the callback, and processing all of the integers. I wonder if you are flooding the output with all of them and that is why you only see the minimum and maximum.

Besides script, you could also do a Change Scale and round or truncate the output to get the integers (if you need a solution).
Regarding using a script it will take me a bit but Ill see if I can help at all.

-S

GDLive · Unread post by **GDLive** » 04 Mar 2015, 18:04

Thank you very much for your help !

I wonder if you are flooding the output with all of them and that is why you only see the minimum and maximum.

I imagine it's something like that, but same result in Process or ProcessIDLE procedure !!

sephult · Unread post by **sephult** » 04 Mar 2015, 18:07

So I have the same problem a lot of times regarding outputting values sequentially.
So everything runs on blocks, I was working on MIDI messaging a short bit ago and bsork guided me that I needed to do a counter and run my procedure in the process.

I only have about 20 mins, but I am going to try and apply that logic to rewrite this. If you don't hear from me I'll try and respond later, hopefully with some code and some guidance.

-S

GDLive · Unread post by **GDLive** » 04 Mar 2015, 18:20

Very kind ! Don't stress, since I'll have to get my childs.. I'll be back late on the forum or tomorrow.. Nothing urge !

sephult · Unread post by **sephult** » 04 Mar 2015, 18:22

So the confusing thing about what you are wanting to get from this.

Are you trying to time your integer output based on the input changes?
If so when you are doing the callback based on the -10/10 values, are just flooding the integers in between to the output....like saying

I saw -10 and 10 so the difference is 20. So I am going to output as one data "-10,-9,-8,-7.........7,8,9,10);

I am still not understanding what your final use of this is for, that might make a huge difference on how you do.

-S

sephult · Unread post by **sephult** » 04 Mar 2015, 18:26

So like I might understand this as, you are determining the values of integers between -10 and 10 for the min/max of an oscillator,
if you want to output the integers do you want to base this on the division of the frequency difference of the oscillator.

That might make the script a lot more complex, and if that was the case I would just run the oscillator as a sine wave into a round module and feed the counter.

Just curious I understand where you are going, I just don't know the destination...lol

-s

GDLive · Unread post by **GDLive** » 04 Mar 2015, 21:52

Ok, what I want to do :

I'm trying to do a "generic" patch for a new control surface I bought. (Icon iStage). It's possible to use this hardware like a launchpad (led matrix). If I want to use one line or one column like a vu meter, I should be able to send parameters to light on or off the addresses.

=> I've an input between min and max. This value could jump from 3 to 10 or go back to 0 without intermediate values.
To illustrate this input, I want to light-on leds with a scale according to theses values.

From -20 to 20, I want to have 40 values and 40 has changed trig to send midi messages.

- I could do this with simple logical tests, but I prefer more common solution, since everybody would not chose the same number of steps.

- a module like "smoother data" would do the job, except if changes are to quick (miss some intermediate values in this case, (smoother focusing on start and end)

- I could do this with a ramp or counters, but in my view it's easier to script that.

The oscillator with square wave is just here to test the principle in extreme changes.

I wanted to go deeper into Hollyhock features and learn scripting, I really want to know what is wrong.

You're right, I saw in the documentation that for midi messages, we have sometime to fill an array before setting it to the output. May it's something similar here, but I don't know why, and feel a little confusing about that.

For example, should the script be executed in on bloc only (even in idle proc..) ?

I hope it's a bit less confusing now...

GD

sephult · Unread post by **sephult** » 05 Mar 2015, 00:16

awesome thanks for the update gdlive, gonna process this a little...brain putting out for the night.

Yeah, so setting one value right after another to an output will just leave you with the last number, since everything happens so fast.
So in my case I sent midi message and it would never turn off. If I changed the length right after the loop nothing would send. (it just recognized to shut off quickly).
So I had to do a counter and put in the process to shut my midi off, on bloc count. Basically on the next bloc it processed again.
So I am wondering if your output needs to be happening in the process section as well.

Ill take a look later when my mind is a little clearer.:/

-S

sephult · Unread post by **sephult** » 05 Mar 2015, 12:26

Awesome I actually get what you are trying to do now. So you want to light these pads as a VU meter. So if the value changes quickly, you want to fill in the pads up to the max value correct?

I have not implemented VU to pads yet, I have a Launchpad, Traktor Controllers and just picked up an Akai APC20 last night.
This stuff is fun for and to me

So from what I see just a Red LED with Brightness control?
I wish NI would build an F1 with a ton of pads, they have HSB control...would be cool to do a multi-color VU.

-S

sephult · Unread post by **sephult** » 05 Mar 2015, 12:39

When you say -20 to 20, are you specifying in dB since you are wanting to use as VU meter?

-S

GDLive · Unread post by **GDLive** » 05 Mar 2015, 12:54

Hello, thanks for the replies.
I would prefer normal scale as integer for a multi-usage script.
For example, I plan to use it also to represent a controller value.

About the icon istage, I tried with no success to get informations from the support about the traktor mode or mackie control mode. Without that, I only can switch on/off red light with midi messages, and can't turn off blue and pink background

About the intial pb, I saw this which seem's to explain similar situation for midi : http://www.sensomusic.com/wiki2/doku.php?id=hollyhock:manual:modules:scripts:template

sephult · Unread post by **sephult** » 05 Mar 2015, 12:57

So give me your thoughts about below, I think this might be the direction you need to be going:

So here is just a thought and pseudo that I was wondering would work.
I am most definite the problem you are having is that you are shoving all integers at once onto the output, instead of a bloc by bloc change of the values.
You were basically creating a messages consisting of all values at once rather than a value change. This is probably why you were only seeing the min/max.

If you are wanting to take an audio input and convert these to respective MIDI values here is just a suggestion or idea for inspiration that might get you somewhere.
So from what I gather now you want to scale a dB value to MIDI to output to your iCON controller for display of level.

This might just be as easy as doing the MIDI from the script and filling in the respective midi values, rather than filling in integers and sending out and converting externally.

Use ENV Follower and pump the dB value into a ptDataFader(max sure to scale in INIT procedure), Below is just a pseudo and not actual tested code.
Hopefully to stimulate some thinking in this direction, I can help do the MIDI portion, and for your case of pushing too many integers where it wasn't working...we can push MIDI that way as much as your controller can take:

Code: Select all

Procedure Process;   
begin                
                 
                
 inval &#58;= getValue&#40;input&#41;;     
                           
 if inval > -20 then begin
   if inval < 20 then begin
             
     inval_round&#58;=round&#40;getValue&#40;input&#41;;
     //db value from ENV Follow Rounded to Integer
     //Just need to scale to correct MIDI values
     //Then you could just output the MIDI messages direct
     //While building the filler for the < messages.
     //Example if receive a 20 here, you can send
     //messages all leading up to 20
     //if you receive a 15, send messages up to 15...etc..
   end;  
 end;

end;

sephult · Unread post by **sephult** » 05 Mar 2015, 13:03

So if we can get something working for you I think then you can do some real audio tests in relation to how fast your controller can respond.
I would be more worried about how fast the control can respond to your message changes. This might become the deal breaker.

I have issues with some controllers, the F1 is pretty quick, but doing things like pushing 16 Brightness values to "0" within one bloc it misses about 3 or 4 of the messages and takes a resend or process to split these messages.

sephult · Unread post by **sephult** » 05 Mar 2015, 13:26

So have you tried to use a Create MIDI module and scan through to see if you can Reverse engineer the MIDI mapping?

I just did this with the Akai APC20 last night, which consequently has no MIDI info since its an Ableton specific controller.

-S

GDLive · Unread post by **GDLive** » 05 Mar 2015, 21:49

Here we are.

Trying to count blocs in the process and wait for this sum in the callback procedure => no success. One the callback has begun, it seem's that the process is in stand-by.

Then I did the opposite, as proposed in midi script : loop in the main process => it work's.

here's the code. looks strange because I adapted my previous code.. not optimized, but works.

I'll post script and patch once it will be finalized.

[c]
// Callback procedure
Procedure Callback(N:integer);
begin
if (N=dataIn) then begin
current := getvalue(dataIn);
end;
end;

// Global variables

//////////////////////////////
// main proc
//////////////////////////////
Procedure Process;
begin
if (current<> past) then
begin
i:=getvalue(dataOutContinious);
if (abs(current-i)>=1) then
begin
countWaits :=countWaits+1;
if (countWaits > MAX_WAITS) then
begin
i:=i+(current-i)/(abs(current-i));

SetValue (dataOutContinious,i);
countWaits :=0;
past:=i;
end;
end;
end
else begin
countWaits :=0;
end;
end;
[/c]

With a few try, it's seem's that I've a good response for the istage, -no lights forgotten even with quicks changes.

I've to try further and with audio, but it look's great.

For the reverse engineering, I planned to do that if I've time.. But to understand tracktor protocol, I've to find someting to send some of those messages !

I'll let you know !

Many thanks for all your answers !

GDLive · Unread post by **GDLive** » 05 Mar 2015, 22:04

awesome for a vu-meter, I've to post a video !!!

To bad I'm just able to change one color

sephult · Unread post by **sephult** » 05 Mar 2015, 22:14

Awesome to hear GDlive!!!

Im glad got you going the right direction, now you have my mind running around figuring different ways to handle too... hahaha.

I've got two Traktor F1's and almost done with my companion interface, quite possibly I could merge the two for a super sequencer or do a VU meter
based on your idea as well. Interestingly enough the HSB of the Traktor matches HollyHocks quite well when scaled, so I can set colors from HollyHock for color-mapping easily.

Be interesting to adapt and work your script maybe a generalized audio to LED VU meter patch will arise for several different controllers!
I still have Traktor F1, Traktor S4, and Akai APC20 to work, so would be interesting to see how well it would adapt.

Very awesome to hear progress!
So do you use Traktor as well in your setup I gather?

-S

GDLive · Unread post by **GDLive** » 06 Mar 2015, 08:09

No, I don't use traktor, and this is my problem to reverse engineer the hsb protocol, on which I could'nt find informations. In theory, the istage is traktor compatible, there are map on internet, but I don't know how to convert the messages.

I'll miss some time today, but my goal is to post a patch for istage, which could be easily adaptable for any control surface I suppose, since it's only midi out

GDLive · Unread post by **GDLive** » 06 Mar 2015, 08:20

About this topic, it would be useful if someone of the team could confirm our hypotheses about interactions between callback and process procedure, and with the set output refresh possibilities vs nb blocks in a callback procedure.
In my mind, those informations could be added in the script callback help topic or script structure help topic.

martignasse · Unread post by **martignasse** » 06 Mar 2015, 10:42

hi GDLive and sephult,

You are on the right track

I'll take time to explain this has i'am actually documenting it in the upcoming SDK user's manual

and because it's very important to understand it.
It's one of the key point of the Usine engine.

I can explain the logic behind this, i'll try to keep it simple...

Parameters :
they are containers for some pieces of data.
there is no assumption of the use you make of this data, for logic, for audio...it's just numbers

The callback procedure :
is called when a parameter data change, it's the "event flow" of Usine and is completely time independent.
generally, we use this procedure to directly respond to a param change, but we can also just collect info to be processed somewhere, has we don't have time reference here.

The process procedure :
is called in sync with audio blocks, it's the "streaming flow" of Usine and precisely timed.
the granularity depend of the buffersize, samplerate of the audio driver and the buffersize of usine.
it's where we naturally process audio blocs but it's also where you can do other thing in sync with the time.
it's literally the "time slice" of the Usine engine.

Consequences
now, you see that using SetValue on the same param in a while or a for loop is irrelevant.
the best way to do some param change in sync with time, or an ordered sequence of param changes, is to do it in the process procedure.

There is lot more to say, but here you have solid piece of infos to understand the Usine heart

let me know if you need precisions

GDLive · Unread post by **GDLive** » 06 Mar 2015, 10:53

Et bien woualà !!!

Thanks Martin, and keep on doing this great job !!

sephult · Unread post by **sephult** » 06 Mar 2015, 12:47

Hello!

Awesome Martin!
I just saw your reply, that is great info. We will have to make sure it gets in the Wiki in the form of the scripting engine as well as the SDK.
I run into this problem constantly, and I have heard many others who do too. When HH2 comes out I can do some description patches, tutorials, and/or video tutorials to help demonstrate. Maybe I can teach myself to follow consistently, I seem to learn by mistake, and repeated mistake quite often

gdlive-
So I use Traktor, if you want to shoot that file my way to sephult@hotmail.com, I can look and see if I find anything of use.
As far as reverse engineering, you can just use the Create MIDI module, and start scanning through at least the CC and Note numbers to see what happens. Not only that just connect the output and view the incoming messages to start deciphering.

As far as the Traktor file, I can get you a list of what they do map and you can compare to what you know. Maybe there are some functions that you do not have yet.

-S

sm_jamieson · Unread post by **sm_jamieson** » 07 Mar 2015, 03:09

Some observations I've found while writing my keyboard zone script (still ongoing):

1. For each bloc, the callback procedure is called first if any parameter has changed value. After this the process procedure is called. My script relies on this order to function. I have not yet looked at the processIDLE procedure but I have to move some code into there soon.

2. I would expect only one output parameter value change to be registered per bloc. Usually changing the value every bloc would be too fast so you would count a number of blocs and then output a value, then count blocs again, etc. like GDlive's example above.

When I've finished my script it should contain several techniques that might help others. But doing it in my spare time with a little girl and another one on the way, it takes time !

Simon.

GDLive · Unread post by **GDLive** » 08 Mar 2015, 11:01

@Simon : uSine is a exceptionally frustrating tool for young parents, I confirm

Welcome to %s forums

Missing values on script output

Who is online

Login • Register