Sensomusic

#1 2018-05-11 16:58:27

imodularsynth
Platinum Member

Hello guys,
the question will probably look stupid, but I could not find any answer both in SDK documentation, SDK source code or the forum.
So I decided to ask it here :

How can I create an integer event? When I look to TParamType, I can't find any integer type. The only "integer like" thing I find is the ptPointer, but I don't want to use something like that

I have seen in other discussions that we all assume that Usine only handles float for events, but integer seem to exist in Usine : they appear for example on Midi In module (Usine says "type integer" when the mouse goes over the I/O of the module). But I could not find in any place how to make such an I/O

And subsidiary question : once I have a integer event, how can I set the event value? The sdkSetEvtData only accepts a float as a parameter (subtyped as TPrecision). I can always cast my integer to the 32 bits used for the float, but I would prefer a more proper way to do this

I absolutely need an integer, since the values I need to code are on 32 bits (the 24 bits of IEEE754 mantissa are not enough for my application)

Thanks

Benoit

Offline

 

#2 2018-05-11 20:30:19

23fx23
Community

afaik there are not really integers params, they are float params where man can write integers values.
so indeed yes as far as i understand you can only encode 24b integers on the 32b float tprecision params.

there is a special type that are Tcolors (orange ones), they are 32 bits RGBA integers, so while seem convoluted, could use that as workaround.
but be aware all maths modules, wires ect, that are not color type are using float32, so it will be tricky to really use your output inside the nodal.

Offline

 

#3 2018-05-12 04:58:13

imodularsynth
Platinum Member

23fx23 wrote:

afaik there are not really integers params, they are float params where man can write integers values.
so indeed yes as far as i understand you can only encode 24b integers on the 32b float tprecision params.


23fx23 wrote:

so it will be tricky to really use your output


Hi23fx23,
thank you for your answer.

During my investigations, I think I have found how Usine handles the values in wires. Maybe I am wrong but I think Usine considers only packets of 32 bits data (hence the "longbool"), it does not care if it is float, int or anything else (apart with MIDI and strings, which are encoded as bytes, as far as I could see). That's probably why the TColor trick is probably working too.

So I think it will not be so tricky as long as the receiver expects 32 bits data on the input (it has to know how to handle it)

But the main question remains : how do we get the "type integer" display on the I/O, like for MIDI IN module? They exist both in HH2 and HH3, as you can see here http://www.sensomusic.org/forums/uploads.php?file=Type%20Integer.PNG
but I can't find a way to display this type

Benoit

Last edited by imodularsynth (2018-05-12 04:59:06)

Offline

 

#4 2018-05-12 11:02:11

oli_lab
Platinum Member

I maybe OT  :
the data input is common to float and integer,
it is when you get the value from the input (or send a value to an output) that you should operate a cast :

float cutoff = sdkGetEvtData(m_cutoff);

int type = int(sdkGetEvtData(m_type));

Olivar


http://oli-lab.org

Win10 I7/16GB RAM  - RME MADIFACE - SSL alpha link 4-16 - OSC capable interfaces

follow OLI_LAB adventures on Facebook
http://www.facebook.com/pages/OLI_LAB/3 … 506?v=wall

Offline

 

#5 2018-05-12 16:31:27

23fx23
Community

the problem i think is all data input base modules in incuded library (purple pins), like a fader, a math A+B ect.. are Tprecision data type, you can't  for ex  add 2 32bit large integers and get a coherent result, or even type a 32bit in in their value field if man try for ex. for ex try to type 16777217 on a fader, we can't, it will be rounded to 16777216. above the 24bit prec there is loss of precision.

so i do feel that even if you were to output a 32 bit integer, all 'float' modules will interpret the 4bytes as a 32bit float, they don't really 'adapt' to what you feed in, their way of working and interpreting the flow  is defined by how the parameter type was set  when the receive module itself was compiled (ie A+B will use and expect float, color will use and espect 32b integers  midi 4 bytes ect). you would for ex have to comile your own A+B with a different type, but i higly supect the one we see on midi are not really 32b ints, but 'false' float with a special display type rounded and  limited to 24b to be compatible with the standard data flow.
I have to double check, but i don't think we have access to integer type in sdk currently .

I remember having the problem when i wanted to make my own HSLA modules, i couldn't really patch it because numbers were too high,  usine first used RGB and there was no need for a special type because it fitted in 24bit prec, when it started using HSLA, the new Tcolor type was created, i suppose especially for those kind of issues. thats why there are special types of  array / mixer /selector ect for colors, other wise we could simply use the data 'standarts' ones

Offline

 

#6 2018-05-12 17:26:10

imodularsynth
Platinum Member

oli_lab wrote:

I maybe OT  :
the data input is common to float and integer,
it is when you get the value from the input (or send a value to an output) that you should operate a cast :

float cutoff = sdkGetEvtData(m_cutoff);

int type = int(sdkGetEvtData(m_type));

Olivar


Hey Olivar,

that's exactly what I have in mind. As I described in my previous answer, I noticed that sdkGetEvtData() acts exactly like a memcpy(), I mean that it copies the four bytes without casting anything. The real cast is in fact performed by the compiler when it finds the variable assignation. The trick I use is to instanciate a float variable which receives sdkGetEvtData() return value. I just point an integer to the float address, and I am able to get the 32 bits from the input without loosing any accuracy.

I will perform some further tests this weekend, using my debugger to see exactly how Usine performs the data transfer, but I think it is completely transparent.

But once again, the question is : how does Usine display the "type integer"? There is is clearly a parameter type defined as an int that Usine recognizes, but I can't find it. Maybe the answer will come our friends of Sensomusic after the weekend...
The problem is that my module sends an int, but Usine says it is a float, which can disturb the user

Benoit

Offline

 

#7 2018-05-13 15:13:45

oli_lab
Platinum Member

you can use integers up to 24 bit that is what a 32bit float is capable of.
I don't know what you're planning, but that's quite a number.
I had this issue sometime ago  :
http://www.sensomusic.org/forums/viewtopic.php?id=5328


http://oli-lab.org

Win10 I7/16GB RAM  - RME MADIFACE - SSL alpha link 4-16 - OSC capable interfaces

follow OLI_LAB adventures on Facebook
http://www.facebook.com/pages/OLI_LAB/3 … 506?v=wall

Offline

 

#8 2018-05-13 17:56:23

sm_jamieson
Platinum Member

oli_lab wrote:

you can use integers up to 24 bit that is what a 32bit float is capable of.
I don't know what you're planning, but that's quite a number.
I had this issue sometime ago  :
http://www.sensomusic.org/forums/viewtopic.php?id=5328


I tried to use colors to send integers and that did not always seem to work - anytime Usine processed it was treated as 32 bit float.
I my ParamMux module, I split colors into 2 halves to send in an array, and I actually sent midi in 4 array floats just to keep it simple.

Simon.

Offline

 

#9 2018-05-13 18:57:20

oli_lab
Platinum Member

you could use the HSLA format, it only use 4 floats !?

or convert any number in string of character like with OSC I think.

Last edited by oli_lab (2018-05-13 19:26:12)


http://oli-lab.org

Win10 I7/16GB RAM  - RME MADIFACE - SSL alpha link 4-16 - OSC capable interfaces

follow OLI_LAB adventures on Facebook
http://www.facebook.com/pages/OLI_LAB/3 … 506?v=wall

Offline

 

#10 2018-05-25 12:25:54

sm_jamieson
Platinum Member

Regarding getting 32 bits sent that can be preserved as a 32 bit int, I don't know if the new ptBitwise parameter type helps - I've not investigated it yet.

Offline

 

#11 2018-05-30 17:15:44

oli_lab
Platinum Member

Hi :
started to look into the matter :

1) should I use UINT32_MAX as the max value of the bitwise input ?
2) when the bitwise input is 1, it reads $3F800000, howzat ?
3) I'm puzzled :/


http://oli-lab.org

Win10 I7/16GB RAM  - RME MADIFACE - SSL alpha link 4-16 - OSC capable interfaces

follow OLI_LAB adventures on Facebook
http://www.facebook.com/pages/OLI_LAB/3 … 506?v=wall

Offline

 

#12 2018-05-30 18:42:01

23fx23
Community

all this stuff is hard to understand^^  didn't try ptBitwise, but feel it has to do that the incoming 1 is entered as float maybe , as seems thats the representation of one in float.

http://www.sensomusic.org/forums/uploads.php?file=float%201.0.jpg

Offline

 

#13 2018-05-30 20:38:44

sm_jamieson
Platinum Member

It ptBitwise is an integer (all bits preserved) value, the value on the wire would have to be an integer also.
So we would need to have a module with ptBitwise output connected to another ptBitwise input. Then if a 1 is sent from the output to the input, the value on the input should be 0x000000001
If it is 0x3F800000 then ptBitwise is not what we think it might be !
But it would be a strangely named parameter type if all bits are not preserved (note 32 bit float only stores integers accurately up to 24 bits).

Offline

 

#14 2018-05-30 20:46:23

oli_lab
Platinum Member

Thanx, I start to understand, so I think : bitwise get a float and convert it in a int32 so we are not limited to 24bits anymore ?


http://oli-lab.org

Win10 I7/16GB RAM  - RME MADIFACE - SSL alpha link 4-16 - OSC capable interfaces

follow OLI_LAB adventures on Facebook
http://www.facebook.com/pages/OLI_LAB/3 … 506?v=wall

Offline

 

#15 2018-05-31 12:52:39

sm_jamieson
Platinum Member

oli_lab wrote:

Thanx, I start to understand, so I think : bitwise get a float and convert it in a int32 so we are not limited to 24bits anymore ?


Almost !
It has to never be a float if it is to have all bits preserved. It can lose accuracy when it is converted to float.
So it cannot be float on the wire - it must be a different flow type, like midi and colors.

But anyway, this is only guessing. The new ptBitwise has not really been explained yet ;-)

Last edited by sm_jamieson (2018-05-31 12:53:58)

Offline

 

#16 2018-06-03 06:13:25

imodularsynth
Platinum Member

Gentlemen, I just got some excellent news from Sensomusic team : they confirm that the ptBitwise is dedicated to handling the 32 bits of data without any conversion.
However, you need SDK 7.01.006 and Usine V1.71 (last versions)

The developers also confirmed that for previous versions, you can use ptColor which is similar in terms of formatting (however, it may look strange to connect 32 bits control parameters to a color on a patch...)
On my side, I have performed some tests (because I want my module to be compatible with older versions of Usine) and I found that ptPointer is interesting to use, because it carries the 32 bits of data "as is". It works flawlessly as long as you connect pointer outputs to pointer inputs.
I started to look to ptIpAddress to, since such an address is made of 4 bytes, but I need to check that Usine sends it as a 32 bits word, not a string like "192.168.0.253"

I also noticed an interesting thing when I look with debugger in the compiled code : as far as I can see, when your code calls sdkSetEvtData() or sdkGetEvtData(), the system just performs a memcpy of the four bytes, it does not check the validity of the data. The potential risk I see is when the 32 bits value is a NaN (Not a Number), which may cause an exception. When Usine carries these data in the "wires", it does not check that data is valid as a float or not (it would cost a lot of CPU cycles to do all the time). As far as I can see, Usine only performs validity checks when it uses the FPU for computation. So at least it's a data transfer, the processor is OK with that.

I plan to make a structured test report about that topic, I will probably post it in the same way as the tutorials I already made.

Benoit

Offline

 

#17 2018-06-03 08:26:23

oli_lab
Platinum Member

I had this NAN issue so I build a foolproof module that put its audio outputs to zeroes.

I also did some  NAN protection on some of my modules that work on chaos principles : double pendulum and chaos oscillator that I plan to release this summer.


http://oli-lab.org

Win10 I7/16GB RAM  - RME MADIFACE - SSL alpha link 4-16 - OSC capable interfaces

follow OLI_LAB adventures on Facebook
http://www.facebook.com/pages/OLI_LAB/3 … 506?v=wall

Offline

 

#18 2018-06-03 09:04:31

imodularsynth
Platinum Member

oli_lab wrote:

I had this NAN issue so I build a foolproof module that put its audio outputs to zeroes.

I also did some  NAN protection on some of my modules that work on chaos principles : double pendulum and chaos oscillator that I plan to release this summer.


Hmmm interesting. May I ask where you have seen the NaN issue? Were they inside your modules or did they happen within Usine when your modules were sending something to Usine ?

Benoit

Last edited by imodularsynth (2018-06-03 09:04:52)

Offline

 

#19 2018-06-04 21:22:41

sm_jamieson
Platinum Member

I suppose the best way to set or get a ptBitwise parameter in a module is using the color event functions:

void    sdkSetEvtColor( UsineEventPtr ev, TColorUsine value )   
TColorUsine  sdkGetEvtColor( UsineEventPtr ev )

Although really, Usine should provide sdkSetEvtBitwise() and sdkGetEvtBitwise() taking unsigned 32 bit values.

Really it is not good practice to assume anything about how Usine sends value internally - although I expect ptBitwise is just sent as 32 bits like most other data.

Simon.

Offline

 

#20 2018-06-04 21:34:35

sm_jamieson
Platinum Member

imodularsynth wrote:

On my side, I have performed some tests (because I want my module to be compatible with older versions of Usine) and I found that ptPointer is interesting to use, because it carries the 32 bits of data "as is". It works flawlessly as long as you connect pointer outputs to pointer inputs.

Benoit


In 64 bit Usine, is ptPointer 64 bits in size ?

SDK has:
void    sdkSetEvtPointer( UsineEventPtr ev, void* value )                                               
void* sdkGetEvtPointer( UsineEventPtr ev )     

Simon.

Offline

 

#21 2018-06-05 05:58:50

oli_lab
Platinum Member

imodularsynth wrote:
oli_lab wrote:

I had this NAN issue so I build a foolproof module that put its audio outputs to zeroes.

I also did some  NAN protection on some of my modules that work on chaos principles : double pendulum and chaos oscillator that I plan to release this summer.


Hmmm interesting. May I ask where you have seen the NaN issue? Were they inside your modules or did they happen within Usine when your modules were sending something to Usine ?

Benoit


Usually when I abuse Usine with loopback on delays... can be avoided with a "soft clipping" module inside the loopback flow.

A nan will kill a filter or a delay and it propagate along the modules that are connected to each other, so I made a "nan" barrier to protect the modules downstream.

it is mainly for tests, but the "fool proof module" is capable of blocking the nasties : NAN, DC, denormal and sending infos for thr trace system.

cheers


http://oli-lab.org

Win10 I7/16GB RAM  - RME MADIFACE - SSL alpha link 4-16 - OSC capable interfaces

follow OLI_LAB adventures on Facebook
http://www.facebook.com/pages/OLI_LAB/3 … 506?v=wall

Offline

 

#22 2018-06-09 14:34:50

sm_jamieson
Platinum Member

I just noticed when you have a ptBitwise terminal and hover over it, the description says "type byte".
That's a bit odd, if it is 32 bits - byte usually means 8 bits. Has anyone confirmed that 32 bits are transported ?

Offline

 

#23 2018-06-13 12:33:48

sm_jamieson
Platinum Member

Well, 32 bits certainly are transported.
I was previously trying to transport large 32 bit integers in an array. If I extracted the value from the array the value was not corrupted, i.e. it was OK on the wire. But when the event was received by the array terminal any values above 24 bits were corrupted or blocked (this might have been due to problems with the Min and Max values on the parameter). Because of this, colors could not be transported in an array.
When I changed the input parameter from ptArray to ptBitwise suddenly the colors were coming through fine.

What I have realised is that an event is just a collection of 32 bit values (depending on the event size).
So actually, anything can be an "array" regardless of using the ptArray parameter type - just set the event size to the size of the "array". Of course the module might only look at the first item. But the new color array flow just uses an color input parameter that looks at all the colors in the event, rather than just the first one.

Note that some parameter types modify or limit the values when they are received. For example:
- the array input parameter blocks or corrupts large integers
- the text input loses all characters after the first zero terminator (a text flow is each ascii character converted to 32 bit float with a zero terminator)
But a ptBitwise input is guaranteed to not alter the value on the wire in any way.

You can use ptBitwise to see exactly what is on the wire, for example a midi note on, note 63, volume 100, channel 2, is stored as $643F9002 = <volume><note><message><channel>.

Last edited by sm_jamieson (2018-06-13 12:37:40)

Offline

 

#24 2018-06-13 16:26:42

imodularsynth
Platinum Member

Hey sm_jamieson,

you worked faster than me :D
I started to make tests with a new module with ptBitwise support, and I have reached the same conclusion than you.
The good thing with ptBitwise is that we are not forced anymore to use some "strange" types like ptColor or ptPointer. By the way, I confirm my assumptions : it's possible to deal with 32 bits integer even under HH2, but then we need the strange types to avoid any unexpected type conversions.
I checked with a debugger how Usine carries the data within the wires : I confirm my second assumptions, Usine does only perform a copy of values from the module to the wire and from the wire to the module. It does not perform any kind of typecast.
Since I want my modules to be still compatible with HH2, I have created a compilation option so I can generate the HH2 version which uses masked types, and a HH3 version with native ptBitwise support

Benoit

Offline