Ingreso rápido:  

Forum: VirtualDJ Plugins

Tema: precisions about difference between repeat_start and repeat_start_instant needed

Este tópico es antiguo y puede contener información incorrecta para la nueva versión.

NicotuxHome userMember since 2014
repeat_start and repeat_start_instant differences other than just starting before or after first loop:

what i experiment :

Pad 1:
pad 2 & play

Pad 2:
repeat_start 'rept' 30ms 1 & nothing
Pad 2 will never return in this case and play will never execute

with pad 2:
nothing
there is no problem, play is executed

with pad 2:
repeat_start 'rept' 30ms 1 & repeat_stop 'rept' &...
Pad 2 does not return - even the loop is executed once and following actions are too

with pad 2:
repeat_start 'rept' 30ms 1 & nothing
Pad 2 does not return

with pad 2:
repeat_start_instant 'rept' 30ms -1 & repeat_stop 'rept' & ...
returns hearly - i.e.: returns to pad1 before Pad 2 ends as if pad 2 were a thread, following actions being executed as well once

with pad 2:
repeat_start_instant 'rept' 30ms -1 & nothing & ...
returns - as if pad 2 were a thread - even pad 2 is an infinite loop, following actions being executed as well all the time forever

it looks like repeat_start + repeat_stop is breaking the whole process chain at the end of the current one
and looks like repeat_start_instant is detaching the current loop from the process chain

Can someone explain or correct me ?
 

Mensajes Wed 03 Jul 19 @ 2:32 am
I don't get your coding examples.
Anyway, the real difference between the 2 commands is not when they count the loop, but when they start executing.

repeat_start 'this' 5 500ms & something

The "something" action will execute 5 times with 500ms intervals. The first execution will happen AFTER 500 ms

repeat_start_instant 'this' 5 500ms & something

The "something" action will execute 5 times with 500ms intervals (same as above). The first execution will happen RIGHT NOW

So, it's not about counting the loops, but when the first execution will occur.

Try this:

repeat_start 'this' 4 2000ms & play ? pause : play

repeat_start_instant 'that' 4 2000ms & play ? pause : play

Finally:
using "pad X" action to chain complex actions together is not a good idea.
The action itself was meant to be used on controller mappings to trigger the actions of the pad, not as a way to combine multiple actions to one.
For complex tasks it's always better to bind the actual actions together.
So, to me your examples seem more like a failure of using the correct actions in a single sentence, rather than a problem with repeat_start actions.
 

Mensajes Mon 08 Jul 19 @ 11:47 am
NicotuxHome userMember since 2014
I precised "other than just starting before or after first loop" of course this one is "opefully" well known

"Quote"
using "pad X" action to chain complex actions together is not a good idea.
"/Quote"

Using unused pads as a subroutine for some actions is something common... maybe a bad usage but common use now

"Quote"
For complex tasks it's always better to bind the actual actions together.
So, to me your examples seem more like a failure of using the correct actions in a single sentence, rather than a problem with repeat_start actions.
"/Quote"

The problem with binding actions together is many actions are NOT always usable in combination with other ones or queries.

Many heavily complex scripts actually can't work in one script pad line when they work fine splitted in 2 or more pads.
This is a side effect with the way parameters are passed to verbs and default parameters or possible multiple interpretations of parameters by some verbs.
Some verbs act differently depending on number of parameters they receive or even their type and results from previous action may interfer.
The use of a second pad in this situation often fixes misunderstanding of parameter list as no parameter is init at second pad start.
Not all the time because some verbs don't work in scripts when not alone.

Another one good reason is : to use "pad x" many times in a script is better than duplicate a very long script part as many times.
If using "pad x" were a bad idea it wouldn't exist at all in scripting but only in mapping because it does nothing else but chain actions - complex or not - together

I don't consider the difference as being a problem with repeat_start actions at all. It can be a feature to launch parallel tasks in really heavily complex script which can be usefull.

The question is can it be taken in consideration an being used or is it only a strange effect due to implementation that may change in future
 

Mensajes Sun 14 Jul 19 @ 2:30 am
I want to delay the deactivation of plugins. I tried this but it doesn't work.

HRESULT VDJ_API CMyPlugin8::OnStop()
{
SendCommand("repeat_start_instant 'stopPlugin' 2 1000ms & effect_active");

return S_OK;
}

I also tried reversing the settings

HRESULT VDJ_API CMyPlugin8::OnStop()
{
SendCommand("repeat_start_instant 'stopPlugin' 1000ms 2 & effect_active");

return S_OK;
}

Where am I wrong ?
 

Mensajes Wed 21 Oct 20 @ 7:20 pm
I'm not the best programmer when it comes to C++, but wouldn't the 'effect_active' action (send twice by the repeat script) trigger OnStart and OnStop in an endless loop ?

I mean, CMyPlugin8::OnStop() gets triggered when the effect get's deactivated.
Then you send an action to activate it again
Which means that OnStart() will get called. Even if you manage that case, the next loop of the repeat script will turn off the effect.
Which will call OnStop() again... Which will send the repeat command again... <ENDLESS LOOP...>

 

Mensajes Wed 21 Oct 20 @ 9:42 pm
You're right PhatomDeejay. Thank you for your answer.
Here a good way to delay the stop of plugin

//---------------------------------------------------------------------------
HRESULT VDJ_API CMyPlugin8::OnStart()
{
if (FXactive == 0)
{
FXactive = 1;

}
if (FXactive == 2)
{
FXactive = 0;
SendCommand("repeat_start 'stopPlugin' 1000ms 1 & effect_active");
}

return S_OK;
}
//---------------------------------------------------------------------------
HRESULT VDJ_API CMyPlugin8::OnStop()
{
if (FXactive == 1)
{
FXactive = 2;
SendCommand("effect_active");
}

return S_OK;
}
 

Mensajes Wed 21 Oct 20 @ 10:11 pm
locodogPRO InfinityModeratorMember since 2013
Deun-Deun wrote :
I want to delay the deactivation of plugins.


For what purpose? only asking as the API has a flag to let plugings trail when switched off
 

Mensajes Thu 22 Oct 20 @ 3:20 am
AdionPRO InfinityCTOMember since 2006
OnStop() is called when the plugin is already stopped, so it is indeed not the right place to extend the plugin's processing.
Re-Enabling and then later stopping the plugin is also not a good idea since it might introduce a short gap causing glitches.

The recommended way is indeed to use the flag as locodog mentioned:
-Add VDJFLAG_PROCESSAFTERSTOP to the Flags variable in OnGetPluginInfo
-Keep track of the state of your plugin in OnStart() and OnStop() (could be a boolean 'active' that you set to true in OnStart and false in OnStop)
-In OnProcessSamples, when active is false it means your plugin is supposed to stop. Fade out or do the other intended stop processing, and once you are ready to truly stop your plugin, return E_FAIL instead of S_OK.
 

Mensajes Thu 22 Oct 20 @ 7:28 am
@Locodog and @Adion

The purpose is to let the echo plugins fade out the echo when we stop the plugin, instead of stopping it instantly like on my DJM2000NXS.
Thank you for your answers !
 

Mensajes Thu 22 Oct 20 @ 9:27 am
@Adion

I've try and the fade out is top !
But the plugin stops itself about 10 seconds after activation.

I precise there is no XML command at all. Here the modifications in the code :

infos->Flags = VDJFLAG_PROCESSAFTERSTOP; // instead of 0x00;

HRESULT VDJ_API CMyPlugin8::OnStart()
{
FXactif = true;
FXstop = false;
dureeOFF = 0;
return S_OK;
}

HRESULT VDJ_API CMyPlugin8::OnStop()
{
FXactif = false;

return S_OK;
}

HRESULT VDJ_API CMyPlugin8::OnProcessSamples(float* buffer, int nb)
{
..............
..............
for (int i = 0;i < nb;i++)
{
.............
.............
if (FXactif == false)
{
if (DureeOFF == 8 * Bpm) { FXstop = true; }
DureeOFF++;
}
DureeFX++;
}

if (FXstop == false)
{
return S_OK;
}
else
{
return E_FAIL;
}
}
 

Mensajes Thu 22 Oct 20 @ 11:52 am
AdionPRO InfinityCTOMember since 2006
Looks fine like this, except probably change "if (DureeOFF == 8 * Bpm)" to "if (DureeOFF >= 8 * Bpm)" since it's possible that the Bpm changes between 2 calls and you might miss the time where it's exactly that value.
Don't see anything wrong here that might cause it to stop after 10 seconds, so probably add some breakpoints and check in the debugger if all variables have the expected values.
 

Mensajes Thu 22 Oct 20 @ 1:48 pm
Very sorry, due to the wrong incrementation of a counter in my code.
Oddly, this anomaly did not cause the plugin to stop with the infos-> Flags = 0x00;

but i don't have enough knowledge to understand "flags".
I apply blindly :-)
 

Mensajes Thu 22 Oct 20 @ 3:56 pm
AdionPRO InfinityCTOMember since 2006
Only when the flag is set, will the plugin stop on returning E_FAIL.
 

Mensajes Thu 22 Oct 20 @ 4:18 pm


(Los tópicos y foros antiguos son automáticamente cerrados)