Statistics: Posted by GDLive — 08 Mar 2015, 11:01
]]>
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.
Statistics: Posted by sm_jamieson — 07 Mar 2015, 03:09
]]>
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
Statistics: Posted by sephult — 06 Mar 2015, 12:47
]]>
Thanks Martin, and keep on doing this great job !!
Statistics: Posted by GDLive — 06 Mar 2015, 10:53
]]>
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
Statistics: Posted by martignasse — 06 Mar 2015, 10:42
]]>
Statistics: Posted by GDLive — 06 Mar 2015, 08:20
]]>
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
Statistics: Posted by GDLive — 06 Mar 2015, 08:09
]]>
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
Statistics: Posted by sephult — 05 Mar 2015, 22:14
]]>
To bad I'm just able to change one color
Statistics: Posted by GDLive — 05 Mar 2015, 22:04
]]>
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 !
Statistics: Posted by GDLive — 05 Mar 2015, 21:49
]]>
I just did this with the Akai APC20 last night, which consequently has no MIDI info since its an Ableton specific controller.
-S
Statistics: Posted by sephult — 05 Mar 2015, 13:26
]]>
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.
Statistics: Posted by sephult — 05 Mar 2015, 13:03
]]>
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:
Procedure Process; begin inval := getValue(input); if inval > -20 then begin if inval < 20 then begin inval_round:=round(getValue(input); //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;Statistics: Posted by sephult — 05 Mar 2015, 12:57
]]>
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
Statistics: Posted by GDLive — 05 Mar 2015, 12:54
]]>
-S
Statistics: Posted by sephult — 05 Mar 2015, 12:39
]]>
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
Statistics: Posted by sephult — 05 Mar 2015, 12:26
]]>
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
Statistics: Posted by sephult — 05 Mar 2015, 00:16
]]>
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
Statistics: Posted by GDLive — 04 Mar 2015, 21:52
]]>
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
Statistics: Posted by sephult — 04 Mar 2015, 18:26
]]>
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
Statistics: Posted by sephult — 04 Mar 2015, 18:22
]]>
Statistics: Posted by GDLive — 04 Mar 2015, 18:20
]]>
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
Statistics: Posted by sephult — 04 Mar 2015, 18:07
]]>
I imagine it's something like that, but same result in Process or ProcessIDLE procedure !!I wonder if you are flooding the output with all of them and that is why you only see the minimum and maximum.
Statistics: Posted by GDLive — 04 Mar 2015, 18:04
]]>
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
Statistics: Posted by sephult — 04 Mar 2015, 17:51
]]>
]]>