Developer forum

[tallrobphilp]

Looks like the official reason studios forums (including the developer forum) have closed down so that avenue has gone.

My next problem - I've got a custom display which was working fine earlier today and I can't work out what I've done to break it. I've specified 2 values to be passed through to the display drawing function, both of which are specified in the rt_owner section of the motherboard_def.lua. For some reason (and this wasn't happening earlier) it appears that the first call to my draw_sequencer() lua method is passing nil for one of the 2 props. I had it working earlier but I've clearly done something to break it in the last couple of hours. The subsequent calls to draw_sequencer(props, di, dr) have both values in props correctl, just not the first call.

Is somehow possible for the display drawing function to get called before my C++ class has been constructed? I'm passing a string back to the motherboard like this: -

Code: Select all

TJBox_UInt8 cPatternData[17] = "0000000000000000";
TJBox_PropertyRef motherboardPatternRef = { fCustomPropertiesRef, "PatternString" };
JBox_SetRTStringData(motherboardPatternRef, 16, cPatternData);

There is a first call to draw_sequencer(props, di, dr) where props has 2 values (as I specify) but the sequencer data is nil. A second call gets made and the data is there. I can't work out what the hell is happening and I've been staring at this code for a few hours! It was working earlier, I swear!

Help!

[orthodox]

Looks like the official reason studios forums (including the developer forum) have closed down so that avenue has gone.

They're still up and working. (you have to be logged in at the RS site first)

Is somehow possible for the display drawing function to get called before my C++ class has been constructed?

No. SetRTStingData() can be called only from RT phase, while the objects are instantiated in the RTC.

[ForgottenClank]

Is somehow possible for the display drawing function to get called before my C++ class has been constructed? I'm passing a string back to the motherboard like this: -

No, but you can set a default value for the RT String in motherboard_def.lua. As far as I can tell this is what you have done. It should not be nil for any of the calls if you've set the default value correctly.

[tallrobphilp]

Is somehow possible for the display drawing function to get called before my C++ class has been constructed? I'm passing a string back to the motherboard like this: -

No, but you can set a default value for the RT String in motherboard_def.lua. As far as I can tell this is what you have done. It should not be nil for any of the calls if you've set the default value correctly.

Apparently not. I get this error when I try to load my player "Error message:
Cannot set default for RT owned string." It also says in the docs that the default value is "Not available for RT strings." However it does mention the Very Simple Sampler in the SDK because apparently it sends string data back to the motherboard so I'll have a look at that and see if I can get some insight.

[ForgottenClank]

Apparently not. I get this error when I try to load my player "Error message:
Cannot set default for RT owned string." It also says in the docs that the default value is "Not available for RT strings."

Right, I forgot it doesn't work for RT strings. Just do a catching if statement at the start of the drawing function checking if the value is nil and only draw if it is not. That's what I do.

[mjxl]

Oh yes pls, I would love to have an SDK subsection here.
I'd like to learn more stuff about developing these devices too tbh.

[orthodox]

No, but you can set a default value for the RT String in motherboard_def.lua. As far as I can tell this is what you have done. It should not be nil for any of the calls if you've set the default value correctly.

Apparently not. I get this error when I try to load my player "Error message:
Cannot set default for RT owned string." It also says in the docs that the default value is "Not available for RT strings." However it does mention the Very Simple Sampler in the SDK because apparently it sends string data back to the motherboard so I'll have a look at that and see if I can get some insight.

Do you really need that default zero string value? You can interpret 'nil' value as that string in your display.lua code.

[tallrobphilp]

Do you really need that default zero string value? You can interpret 'nil' value as that string in your display.lua code.

Just to clarify, you CANNOT set a default value for an RT-owned string. I made a mistake with what I said earlier. It was passing an empty string, not nil. When I tried to check if it was nil I got an error about not being able to compare a string to nil. So what I had to do was just check if the value was an empty string and if it was then I didn’t continue the custom drawing code.

I now need to sort out another small issue with when/how the redraw is triggered but I think that shouldn’t be too tricky.

[tallrobphilp]

Can anyone point me in the right direction regarding the storage of custom string data in a patch file? I've made some good progress with a little step sequencer player device I'm trying to build and it basically uses a simple "algorithm" to generate the sequencer data. Because of that, I can specify the controls/properties as part of the document owner in the motherboard so that they get saved.

What I'm curious about, although I may not pursue this yet, is how I can have a custom display with interaction so that you can click steps on and off etc. I understand the interaction part of it in terms of gesture lua functions that react to mouse clicks and movement etc, but I'm baffled about how I can save that data in the document. I've examined the online documentation loads and I can't work out how you can manipulate and then store a long string (which could contain complex pattern data) in the document. I had a look at the XML file for a drum sequencer patch so I know it must be possible, but I can't see how to manipulate the data in a document_owner property from the RT. I can modify an rt_owner string, which is how I'm currently programmatically "generating" a simple sequence and passing that data back to the motherboard to be displayed by a custom display, but I can't save that string. saving/loading currently works because the knobs that control the algorithm parameters are regular document_owner properties. So the algorithm parameters get saved, and the sequencer data is generated in RT based on those parameters and passed back to the display.

In short - is it possible to have a custom display, with interactions, that can control string data that is part of the document_owner motherboard properties, or pass data to the RT which then stores that data in a document_owner string? I had a good dig in the other forum but I couldn't find anything relevant.

Thanks so much for all the help I've received so far, I basically expected to get absolutely nowhere with this but I've already got a working player device after a couple of weeks. It won't set the world on fire as it is but I'm going to keep going until I haven't something a bit more useful and see if I can release it int the wild.

[artotaku]

Can anyone point me in the right direction regarding the storage of custom string data in a patch file? I've made some good progress with a little step sequencer player device I'm trying to build and it basically uses a simple "algorithm" to generate the sequencer data. Because of that, I can specify the controls/properties as part of the document owner in the motherboard so that they get saved.

What I'm curious about, although I may not pursue this yet, is how I can have a custom display with interaction so that you can click steps on and off etc. I understand the interaction part of it in terms of gesture lua functions that react to mouse clicks and movement etc, but I'm baffled about how I can save that data in the document. I've examined the online documentation loads and I can't work out how you can manipulate and then store a long string (which could contain complex pattern data) in the document. I had a look at the XML file for a drum sequencer patch so I know it must be possible, but I can't see how to manipulate the data in a document_owner property from the RT. I can modify an rt_owner string, which is how I'm currently programmatically "generating" a simple sequence and passing that data back to the motherboard to be displayed by a custom display, but I can't save that string. saving/loading currently works because the knobs that control the algorithm parameters are regular document_owner properties. So the algorithm parameters get saved, and the sequencer data is generated in RT based on those parameters and passed back to the display.

In short - is it possible to have a custom display, with interactions, that can control string data that is part of the document_owner motherboard properties, or pass data to the RT which then stores that data in a document_owner string? I had a good dig in the other forum but I couldn't find anything relevant.

Thanks so much for all the help I've received so far, I basically expected to get absolutely nowhere with this but I've already got a working player device after a couple of weeks. It won't set the world on fire as it is but I'm going to keep going until I haven't something a bit more useful and see if I can release it int the wild.

A custom display can persist a document owned string to a patch or a Reason document. An RT owned string cannot be saved to a document or a patch, it is lost. Which means you always need user interacton to "store" something. So while your realtime may calculate some stuff and returns it to the custom display you have to save it to another document owned string as soon as the user clicks somewhere on the custom display so the handlers are fired.
Typically, if user clicks on a step of the step sequencer in your custom display you´d save the steps state in the document string while your runtime starts calculating something which may be displayed after calculation.

Also you have to think about a "protocol" or codec how you save multiple stuff in a single document owner string. If you reverse engineer other player devices in Recon you see that that they typically save the state of the custom display in one or more big strings which is a concatenation of chars where each char/byte may refer to a property value.

E. g. you want to save 16 steps of your step sequencer where each step has velocity, note and length. For example, you could reserve three char/bytes per step and concatenate them to be stored in a patch (step * 3 * 16 = 48 chars).

[tallrobphilp]

A custom display can persist a document owned string to a patch or a Reason document. An RT owned string cannot be saved to a document or a patch, it is lost. Which means you always need user interacton to "store" something. So while your realtime may calculate some stuff and returns it to the custom display you have to save it to another document owned string as soon as the user clicks somewhere on the custom display so the handlers are fired.
Typically, if user clicks on a step of the step sequencer in your custom display you´d save the steps state in the document string while your runtime starts calculating something which may be displayed after calculation.

Also you have to think about a "protocol" or codec how you save multiple stuff in a single document owner string. If you reverse engineer other player devices in Recon you see that that they typically save the state of the custom display in one or more big strings which is a concatenation of chars where each char/byte may refer to a property value.

E. g. you want to save 16 steps of your step sequencer where each step has velocity, note and length. For example, you could reserve three char/bytes per step and concatenate them to be stored in a patch (step * 3 * 16 = 48 chars).

Thanks a lot, that's very helpful. I had already thought about this myself but the documentation says that the "store_property" lua function works in the "Realtime controller" context so I thought this meant I couldn't use it in my drawing function. If I can indeed write to a document-owned property in the motherboard from my lua drawing code then I'll give that a try.

[orthodox]

If I can indeed write to a document-owned property in the motherboard from my lua drawing code then I'll give that a try.

You can't do that directly. You can only update property values via gesture handling, that's why a user interaction is always required for changing a value.

[tallrobphilp]

If I can indeed write to a document-owned property in the motherboard from my lua drawing code then I'll give that a try.

You can't do that directly. You can only update property values via gesture handling, that's why a user interaction is always required for changing a value.

Right, I understand the distinction now. The document-owned property update(s) can be done by the gesture code and then I can use the value(s) in the draw function and the RT C+ code. Brilliant.

[joeyluck]

I know there was talks at some point to create a developer forum/channel. I think it would be a good idea so that we can share publicly.

Any other agree?

Yan
PS: I might have some exciting news to share....

New forum here: viewforum.php?f=61



To everybody who participated in this thread. Please feel free to create your own threads for your individual questions and tips in that new forum to help it along. Thanks!

[pongasoft]

I know there was talks at some point to create a developer forum/channel. I think it would be a good idea so that we can share publicly.

Any other agree?

Yan
PS: I might have some exciting news to share....

New forum here: viewforum.php?f=61



To everybody who participated in this thread. Please feel free to create your own threads for your individual questions and tips in that new forum to help it along. Thanks!

Thank you very much. Much appreciated

Yan