SDK early set chunk

sm_jamieson · Unread post by **sm_jamieson** » 19 Feb 2018, 00:02

It has previously been explained that onSetChunk() is called at a low priority to not slow down loading, which seems reasonable.

I am producing a user module where I wish the data stored in the chunk to affect the number of parameters and parameter types. For that to be possible, onSetChunk() must be called before GetParameterInfo(), onSetEventAddress() and GetNumberOrParameters(), i.e. straight after onGetModuleInfo().

Obviously this should not be the default.
The best way would be to have a field such as "LongBool FastSetChunk" (in similar style to existing flag "LongBool DontProcess") that can be set to TRUE in onGetModuleInfo().

To avoid any problems forced on users, perhaps there could be an Expert setting to ignore this flag (could even default to Ignore).

Thanks,
Simon.

P.S.
In case anyone is interested, I found a different way of storing a unique config for each instance of the module. I used the query system to generate and suggest a unique ID when the module is initially loaded (the popup indicates used and spare IDs), and maintain an external config file against this ID. I can then use some type of Dialog or Windows form to get the information I need and store it against the ID. I've got 512 IDs offered to the user in the query popup which should be quite enough !

YouTube · Unread post by **senso** » 26 Feb 2018, 11:12

interesting but I not sure to understand why you need that?

YouTube · Unread post by **senso** » 26 Feb 2018, 12:59

Platinum Member

Re: SDK early set chunk

OK, I will explain why I wanted it.
The query system provides a single choice from a list. I wanted to write a user module with a more complicated parameter configuration, and also to be able to change this without deleting and re-dropping the module into the patch, which loses all the currently wired connections.
So my idea was to use the module Settings to configure the desired parameter layout, then save this in the chunk. Then next time the module is loaded, or if the patch is reloaded via the patch context menu, the new parameter layout will be there. But for this to happen there needs to be a way to access the chunk very early on in the module init process.

So in summary, it is a way of having a more complex parameter configuration than the query system provides, and also to reconfigure this without having to delete and re-drop the module.

sm_jamieson · Unread post by **sm_jamieson** » 26 Feb 2018, 15:31

Hi Senso,
is there a response missing ? - I am only seeing my post quoted (and it seems to have replaced my actual post !)

YouTube · Unread post by **senso** » 26 Feb 2018, 15:34

I've deleted your post by mistake. sorry...
I'll answer soon.

sm_jamieson · Unread post by **sm_jamieson** » 05 Mar 2018, 10:24

OK, no problem.

sm_jamieson · Unread post by **sm_jamieson** » 28 Mar 2018, 23:16

I've posted an add-on "ParamMux" that would really benefit from this.
It would enable me to ditch the external config file ...

Thanks,
Simon.

YouTube · Unread post by **senso** » 13 May 2018, 09:57

hi,
sorry for the delay.
I spent a long time trying to understand the paramMux.
I think that in this case an new SDK function like sdkSetParamType() could be added to change the parameter's type on the fly.
This could simplify your module ?
senso+++

Unread post by **oli_lab** » 13 May 2018, 17:20

that would be fun !
I cans see application for multitype OSC messages...

sm_jamieson · Unread post by **sm_jamieson** » 13 May 2018, 18:31

senso wrote:hi,
sorry for the delay.
I spent a long time trying to understand the paramMux.
I think that in this case an new SDK function like sdkSetParamType() could be added to change the parameter's type on the fly.
This could simplify your module ?
senso+++

If some of the TParamInfo fields can be changed on the fly that would be very useful. sdkSetParamType() would set the most vital one, and would simply paramMux module greatly.
Ideally most of the TParamInfo field could be changed on the fly rather than just in the module initialisation, but I know not all will be possible.
The possible fields are below. I have marked with an X the ones that should be possible.

X TParamType ParamType
X AnsiCharPtr Caption
LongBool IsInput
LongBool IsOutput
X TScale Scale
X TColorUsine Color
X TColorUsine OffColor
X TPrecision MinValue
X TPrecision MaxValue
X TPrecision DefaultValue
X AnsiCharPtr Symbol
X AnsiCharPtr Format
X AnsiCharPtr ListBoxStrings
AnsiCharPtr TextValue
LongBool ReadOnly
TFastCallBackType CallBackType
LongBool DontSave
LongBool IsSeparator
LongBool IsInvisible
LongBool IsStoredInPreset
AnsiCharPtr SavedName
AnsiCharPtr SeparatorCaption
NativeInt CallBackId
LongBool IsVisibleByDefault
LongBool IsShared
LongBool Translate
UsineEventPtr * EventPtr
AnsiCharPtr FileNameFilter

Obviously ParamType is the most important, covered by sdkSetParamType().
The fields that might need to be modified when the parameter type is changed would hopefully be possible as well, i.e. MinValue, MaxValue, Symbol, Format.
I know ListBoxStrings can already be set on the fly.

Also, I hope the parameter terminal colors on the module in the patch screen would change to match the modified parameter type (else would be rather confusing).

Thanks,
Simon.

YouTube · Unread post by **senso** » 15 May 2018, 18:41

Finally, I'll implement the following procedure
RecreateParam (ModuleInfo* pModuleInfo, int numParam, TParamInfo* pParamInfo);

which recreates totally the parameter.
It's a better and simpler solution.
v171
sdk 7.01.006

sm_jamieson · Unread post by **sm_jamieson** » 16 May 2018, 00:20

Fantastic !

23fx23 · Unread post by **23fx23** » 16 May 2018, 05:38

wow coool

Unread post by **oli_lab** » 16 May 2018, 07:47

wow, cool ! thank you Senso !
if this is possible, would it be possible to change the color of the module on the fly ?

sm_jamieson · Unread post by **sm_jamieson** » 16 May 2018, 14:44

Note, the procedure in the SDK API is
sdkRecreateParam(int numParam, TParamInfo* pParamInfo)

sm_jamieson · Unread post by **sm_jamieson** » 22 May 2018, 01:43

The new function sdkRecreateParam(paramnum, paraminfo) does not work correctly.
Instead of changing parameter number "paramnum" to a new specification, it is adding a new parameter to the module at the end. When the value of this new parameter is changed, it causes a callback error in the OnCallback() routine, and the wParam value contains an invalid value.
If you pass sdkRecreateParam the same specification it already has, it does not create a new parameter at the end.

Any comments, before I raise a bug ticket ?

NOTE: It would be an excellent feature if you could add parameters by specifying a number higher than the existing parameter numbers, but this would mean that pModuleInfo->NumberOfParams would have to be changed too.
But sdkRecreateParam(), as its name says, should recreate an existing parameter number.

YouTube · Unread post by **senso** » 22 May 2018, 12:24

Can you post a bug report mail at support@sensomusic.org
with a user module and a patch example please ?
senso+++

sm_jamieson · Unread post by **sm_jamieson** » 22 May 2018, 15:37

Yes I should get time in the next few days.

sm_jamieson · Unread post by **sm_jamieson** » 23 May 2018, 22:18

Just sent bug report - including zip file with examples.

Welcome to %s forums

SDK early set chunk

Who is online

Login • Register