galaf

how to compile ipcformat on max 8? Source code and object .mxo zip file

ipcformat.zip

Hello
how to compile ipcformat on max 8? Source code and object .mxo zip file
best regards

Hello
how to compile ipcformat on max 8? Source code and object .mxo zip file
best regards

 
best regards G.

ipcformat-iprogramcard

Alternative to trying to recompile that external without agreement form the developer,

you could capture fixed part of the sysex message per parameter and only change the values.

For examples you posted, that are 3 items , first the OSC Transmit Model (0 or 1), then the value, split into 4 0-255 bytes.

As it seems that max fader output is 4094, you would only need 

and it would max at 0 0 15 254 ( 15* 256 + 254 = 4094 )

Here you can compare output of ipcformat to captured sysex message

The sysex strings gets formed based on number of chars in the OSC address and number of parameter - values.

Only a bit more demanding would be to get float values if there are any,

because that would also need to be converted from float to raw bytes.

Alternative to trying to recompile that external without agreement form the developer,
you could capture fixed part of the sysex message per parameter and only change the values.
For examples you posted, that are 3 items , first the OSC Transmit Model (0 or 1), then the value, split into 4 0-255 bytes.
As it seems that max fader output is 4094, you would only need / 256 and % 256
and it would max at 0 0 15 254  ( 15* 256 + 254 = 4094 )

Here you can compare output of ipcformat to captured sysex message 


The sysex strings gets formed based on number of chars in the OSC address and number of parameter - values.
Only a bit more demanding would be to get float values if there are any,
because that would also need to be converted from float to raw bytes.


After reading the explanations it is indeed a question of having to send messages by ipcformat and I absolutely need this this object on max 8.

also it seems useful to find the corresponding osc files OscMessage.h and OscEncoder.h.

The osc language is used on max msp it is curious not to have a database entered in C74support.

The developer gave what you have and told me that it should be enough for me to compile ipcformat on max 8 and I do believe it is imperative to have this object to send this MIDI data.

osc message.png

Hello,
After reading the explanations it is indeed a question of having to send messages by ipcformat and I absolutely need this this object on max 8.
that's why I sent a screenshot of XCode.
also it seems useful to find the corresponding osc files OscMessage.h and OscEncoder.h.
The osc language is used on max msp it is curious not to have a database entered in C74support.
The developer gave what you have and told me that it should be enough for me to compile ipcformat on max 8 and I do believe it is imperative to have this object to send this MIDI data.

thank you I replied on the forum as mentioned but I am still very surprised not to be able to obtain the missing data.

these are the ones that must handle ipc format and this osc data is not just made for this object but for many other applications ...

Hello
thank you I replied on the forum as mentioned but I am still very surprised not to be able to obtain the missing data.
OscMessage.h, OscEncoder.h
these are the ones that must handle ipc format and this osc data is not just made for this object but for many other applications ...
looking forward to your help

You should ask developer to either provide header files or at least name the source.

I remember that header files in ArdOSC library for arduino,

which is discontinued, and replaced by OSC library.

https://www.arduino.cc/reference/en/libraries/ardosc/

lib updated, but most header files are the same.

but maybe you are lookin for different ones ?

You should ask developer to either provide header files or at least name the source.
I remember that header files in ArdOSC library for arduino,
which is discontinued, and replaced by OSC library.

 
download original one from here:
https://github.com/recotana/ArdOSC
or
https://www.arduino.cc/reference/en/libraries/ardosc/
lib updated, but most header files are the same.


The developer or his representative has still not responded.

I'll ask them for the header files again.

Thanks for the osc basics that I downloaded.

I'm looking for nothing other than these missing files ...

I will try to look for a solution and will be sure to notify promptly if a solution is found.

The developer or his representative has still not responded.
I'll ask them for the header files again.
Thanks for the osc basics that I downloaded.
I'm looking for nothing other than these missing files ...
I will try to look for a solution and will be sure to notify promptly if a solution is found.
best regards

2 header files are in the ArdOSC library.

Why don't you simply use them and try to compile the external.

2 header files are in the ArdOSC library.
Why don't you simply use them and try to compile the external.


yes the idea seems interesting but these are data for Arduino and I have to adapt to max and the patch to drive the Iprogram Card which is not an Arduino.

Also having the ipcformat.mxo object on max 7 I'm wondering when trying to read it in Xcode and extract the OSC data ... I'm not a specialist thanks for the help

yes the idea seems interesting but these are data for Arduino and I have to adapt to max and the patch to drive the Iprogram Card which is not an Arduino.
I'm going to try .
I keep you informed of my tests.
Also having the ipcformat.mxo object on max 7 I'm wondering when trying to read it in Xcode and extract the OSC data ... I'm not a specialist thanks for the help

the developer remains silent in front of my many emails it's very heartbreaking ...

Thanks for the research and advice but I did not find a solution and the 2 head ArdOSC files are not readable so another new file is missing and it is not in the Cycling74 data.

I sent a final word to the developer and more precisely his representative.

They don't seem to be able to answer ... according to the explanations the source code allows to manage to create ipcformat on max8, it's curious!

Thanks for the research and advice but I did not find a solution and the 2 head ArdOSC files are not readable so another new file is missing and it is not in the Cycling74 data.
I sent a final word to the developer and more precisely his representative.
They don't seem to be able to answer ... according to the explanations the source code allows to manage to create ipcformat on max8, it's curious!
Pending a possible solution
Best regards

Max MIDI patch simplifié.maxpat

My advice still is to forget that external and use plain max objects to

form sysex messages, as I showed you in the patch I posted.

You don't need to extract any OSC data or such.

just capture the output of that external on Max 7.

Just out of curiosity, I visited that buchla page, and found

few infos about it, and a patch which is used to control that card

There are not too many parameters that need to be controlled.

My advice still is to forget that external and use plain max objects to
form sysex messages, as I showed you in the patch I posted.
You don't need to extract any OSC data or such.
just capture the output of that external on Max 7.
Just out of curiosity, I visited that buchla page, and found
few infos about it, and a patch which is used to control that card
with OSC messages using wifi.
There are not too many parameters that need to be controlled.


That is all allready in patch I posted, did you not

here it is without that external and midi connected

That is all allready in patch I posted, did you not
understand it ?

here it is without that external  and midi connected

thanks it works on the fd_co_pitch parameter

for the other parameters how to be able to differentiate them for each patcher they must be different I do not know how to differentiate them they are 18 see more.

I need to organize a patcher for each and how do I differentiate them so that each patcher controls the right parameter?

also the green command i have a lot of trouble to change patches randomly on the map.

it's great to be able to do without ipcformat which is not needed for this use but i'm still looking to finalize this patch.

ipcard4.maxpat

thanks it works on the fd_co_pitch parameter
for the other parameters how to be able to differentiate them for each patcher they must be different I do not know how to differentiate them they are 18 see more.
I need to organize a patcher for each and how do I differentiate them so that each patcher controls the right parameter?
also the green command i have a lot of trouble to change patches randomly on the map.
it's great to be able to do without ipcformat which is not needed for this use but i'm still looking to finalize this patch.

I can't read and know how this patch works with osc capture

thank you for giving me more details to be able to better understand and add all the parameters as on the patch that you were able to discover, I modified it and everything works except that here I do not know how to find the name of the sysex addresses

I can't read and know how this patch works with osc capture
thank you for giving me more details to be able to better understand and add all the parameters as on the patch that you were able to discover, I modified it and everything works except that here I do not know how to find the name of the sysex addresses

I allready showed how to capture sysex for different parameters in the first patch.

Connect OSC message to that external and watch the list at the output.

You can't copy sysex from one parameter to the other.

when you send message containing osc address and parameters,

that external creates a list which contains code for message length,

then code for number of parameters and parameters themself.

You capture the list and copy it , then replace the parameters with changeable arguments,

like $1 $2 $3 etc, depending on how many they are.

All parameters that have only osc address, mode and value will look similar,

only first part of the message that deals with length and OSC address name

You can tell where it ends, as it is unique number 

 is start of the second part of the list - value length descriptor.

 gets repeated as many times as values in the list and ends with few 0 (zero)

Next are 4 ints per value, easy to follow if you look at the list from right to left

All parameters that have integers as values get sent as 4 bytes 0-255.

Have a look at the picture to understand that.

Screen shot 2021-04-22 at 9.28.11 AM.png

if value does not exceed 255, value will be sent as 0 0 0 nn

if parameter has higher range, like 4096 then one would need 

47 102 100 95 99 111 95 112 105 116 99 104

ignore 240 and 247 = start/end of sysex message

is beginning of the value length and values

gets repeated as many times as values in the list, followed by number of zeros

which are part of length descriptor for value string length

that list of 3 values gets formed with join, set to output when

There was a MISTAKE in the patches I posted, join was set to trigger 2

Screen shot 2021-04-22 at 9.47.35 AM.png

some sources to destinations using float value for connection depth.

Float gets treated differently than integers.

You would need either float to raw int binary to 4 x 8bytes list converter

or if high precision of the float is not needed,

one could capture -1. to 1. range into coll

for example using 2-3 decimal places and use that instead.

Connect OSC message to that external and watch the list at the output.
You can't copy sysex from one parameter to the other.
when you send message containing osc address and parameters,
that external creates a list which contains code for message length,
ascii chars OF THAT OSC message,
then code for number of parameters and parameters themself.
You capture the list and copy it , then replace the parameters with changeable arguments,
like $1 $2 $3 etc, depending on how many they are.

All parameters that have only osc address, mode and value will look similar,
only first part of the message that deals with length and OSC address name
would differ.
You can tell where it ends, as it is unique number 44 that ends that part of the list,
and 105 is start of the second part of the list - value length descriptor.
105 gets repeated as many times as values in the list and ends with few 0 (zero)
depending on the number of values.
Next are 4 ints per value, easy to follow if you look at the list from right to left
ignoring 247 which is end of sysex.
----------
All parameters that have integers as values get sent as 4 bytes 0-255.
Have a look at the picture to understand that.



if value does not exceed 255, value will be sent as 0 0 0 nn
like in case of that /ps_load $1.
if parameter has higher range, like 4096 then one would need % 256 and / 256
to have output 0 0 $1 $2.
/fd_co_pitch $1 message example :
240 28 47 102 100 95 99 111 95 112 105 116 99 104 0 0 0 0 44 105 105 0 0 0 0 $1 0 0 $2 $3 247
ignore 240 and 247 = start/end of sysex message
28 is code for message length
44 is end of ascii part and length code
105 is beginning of the value length and values
105 gets repeated as many times as values in the list, followed by number of zeros
which are part of length descriptor for value string length
next part are 4 integers for each value.
0 0 0 $1   is here for OSC Transmit mode 0 or 1
0 0 $2 $3  is value of the parameter

that list of 3 values gets formed with join, set to output when
inlet 1 gets input.
There was a MISTAKE in the patches I posted, join was set to trigger 2
instead of  @triggers 1 .
I updated uploaded patches


------------------
That is the easy part of it.
There are /cv_connect parameters which connect 
some sources to destinations using float value for connection depth.
Float gets treated differently than integers.
You would need either float to raw int binary to 4 x 8bytes list converter
to form 4 integer float representation,
or if high precision of the float is not needed,
one could capture -1. to 1. range into coll
for example using 2-3 decimal places and use that instead.




There are few obvious mistakes in that Easel OSC Max patches

1- missing slash in Envelope Generator OSC String

2- first slider in Sequential Voltage Source bpatch has

here is captured list of all parameters :

/sw_eg_trigger $1 is fixed - oner must do it in the Easel subpatch too !

SYSEX-LIST-OK.txt

should be used exactly as in my examples.

are the ones that do not need OSC Transmit Mode

You simply connect control to the message.

Screen Shot 2021-04-22 at 15.23.24.png

Screen Shot 2021-04-22 at 15.26.33.png

you click or bang that message to send it

The last item in that text file is the mentioned

Screen Shot 2021-04-22 at 15.30.26.png

 which are OSC Transmit Mode and two menu selected items (numeric)

that one has to be converted as described in my previous post to 4 bytes at the end.

240 36 47 99 118 95 99 111 110 110 101 99 116 0 44 105 105 105 102 0 0 0 0 0 0 $1 0 0 0 $2 0 0 0 $3 

$1 - OSC Transmit mode, $2 - menu selection 1 , $3 - menu selection 2

here is patch using embeded coll with float values converted,

EDITED 24 april 2021 - Sysex List fixed 
There are few obvious mistakes in that Easel OSC Max patches
1- missing slash in Envelope Generator OSC String
sw_eg_trigger $1
should be
/sw_eg_trigger $1
2- first slider in Sequential Voltage Source bpatch has
/easel/fd_svs_level1 $1
which no other OSC String has
I guess correct should be
/fd_svs_level1 $1
-----------
here is captured list of all parameters :
Uploaded 24. april 2021.
/easel/fd_svs_level1 $1 is left as is

/sw_eg_trigger $1 is fixed  - oner must do it in the Easel subpatch too !

all items that end with
$1 0 0 $2 $3 247
should be used exactly as in my examples.
they need OSC Transmit Mode.  
The ones that end with
0 0 $1 247
are the ones that do not need OSC Transmit Mode
You simply connect  control to the message.
Here example for /ps_save


there are few that  send no values, like


you click or bang that message to send it
--------------
The last item in that text file is the mentioned
/cv_connect   which is a special case.

After 3 values 0 2 5 which are OSC Transmit Mode and two menu selected items (numeric)
there is a float connection depth value  -0.570
that one has to be converted as described in my previous post to 4 bytes at the end.
In the sysex string :

240 36 47 99 118 95 99 111 110 110 101 99 116 0 44 105 105 105 102 0 0 0 0 0 0 $1 0 0 0 $2 0 0 0 $3 $4 $5 $6 $7 247
changeable arguments are 
$1 - OSC Transmit mode, $2 - menu selection 1 , $3 - menu selection 2
last 4: $4 $5 $6 $7  are the float value
------------
here is patch using embeded coll with float values converted,
using 3 decimal places precision.



Having received data on OSC I communicate them.

It's very difficult for me to develop on XCode but maybe someone can try?

ArdOSC.zip

Having received data on OSC I communicate them.
It's very difficult for me to develop on XCode but maybe someone can try?
I tried but it is not conclusive.

All these explanations are still useful with the important command table with sysex correspondences, that's fine.

I take the liberty of placing an extracted .xml text file from the Easel208Pad application file.

Also it becomes difficult to operate depending on IOs used.

I have appropriated the known patch that I have modified many times, it has no osc and only the fader and switch controls plus the change of patches from 0 to 23.

My operation is on USB cable mainly to be operational in old walls without internet connection.

What is the function to read the output of ipcformat link in green? I couldn't figure out how to do it.

I have to keep reading to understand better I appreciate it.

randmetaltxt.txt

All these explanations are still useful with the important command table with sysex correspondences, that's fine.
I take the liberty of placing an extracted .xml text file from the Easel208Pad application file.
Also it becomes difficult to operate depending on IOs used.
There are many decimals beyond 3.
I have appropriated the known patch that I have modified many times, it has no osc and only the fader and switch controls plus the change of patches from 0 to 23.
The OSC on WIFI mainly?
My operation is on USB cable mainly to be operational in old walls without internet connection.
What is the function to read the output of ipcformat link in green? I couldn't figure out how to do it.
I have to keep reading to understand better I appreciate it.

The discovery of unknown or used functions on the application?

copyLiveToBuffer, clearBuffer, cv_connect, ps_save, ps_load, debug_text

Indeed, I saw entries that did not correspond to anything but everything is quite complex!

It is likely to save their card directly with max but this is to be discovered gradually ...

The discovery of unknown or used functions on the application?
copyLiveToBuffer, clearBuffer, cv_connect, ps_save, ps_load, debug_text
still a lot to discover and thank you!
Indeed, I saw entries that did not correspond to anything but everything is quite complex!
It is likely to save their card directly with max but this is to be discovered gradually ...

I am afraid here end my possibilities to help you with that card.

That list I posted with osc messages are extracted from easel max patches,

every single control sent to the ipcformat external and output captured

If they are correct, then it should work.

the only float value in that patch is in the 

fd_svs_4="2229.040283203125" use 12 decimal places precision

where in max patch it is a plain integer ?

Probably mistake, either in iPad app or in the max patch.

To conclude, I posted everything you need to send sysex

using plain max objects, rest is your decision, to use it or not.

you would have to convert float to binary.

Float.floatToRawIntBits(f); function, and then do bitshifting to get 4 ints list

I am afraid here end my possibilities to help you with that card.
That list I posted with osc messages are extracted from easel max patches,
every single control sent to the ipcformat external and output captured
to form sysex string.
If they are correct, then it should work.
the only float value in that patch is in the /cv_connect parameters
all other are plain integer.
why does for example in that xml file
fd_svs_4="2229.040283203125"  use 12 decimal places precision
where in max patch it is a plain integer ?
Probably mistake, either in iPad app or in the max patch.
-------
To conclude, I posted everything you need to send sysex
using plain max objects, rest is your decision, to use it or not.
If you need more decimal places for the /cv_connect parameter
which I doubt would make any difference
you would have to convert float to binary.
in java one would use 
Float.floatToRawIntBits(f);  function, and then do bitshifting to get 4 ints list


from the xml text file you uploaded it is visible that

5 Sequential Voltage Source faders are adressed :

so that must be a mistake in the easel max patch.

P.S. one more correction
from the xml text file you uploaded it is visible that
/easel/fd_svs_level1  or what I thought could be correct /fd_svs_level1  does not exist.
 5  Sequential Voltage Source faders  are adressed :
/fd_svs_1
/fd_svs_2
/fd_svs_3
/fd_svs_4
/fd_svs_5
so that must be a mistake in the easel max patch.


/ easel / fd_svs_level1 $ 1 is readable on the bpat_SVS patch.

I didn’t modify anything on the .xml but just provided it for informational purposes.

the change of program / ps_load is a concern.

After long testing the original patch with ipcformat midi is stable.

For tests by following the attached patch, the midi is not stable and the card becomes silent.

by changing the values ​​on Complex OSC Pitch, data is transmitted for a very short time.

The card also switches to WIFI onOFF mode during the tests on copitch.

/ easel / fd_svs_level1 $ 1 is readable on the bpat_SVS patch.
I am using the app to save to the card.
svs_level_1 works on iPad.
I didn’t modify anything on the .xml but just provided it for informational purposes.

attached a patch to test
the change of program / ps_load is a concern.
the programs do not change on the card.

For tests by following the attached patch, the midi is not stable and the card becomes silent.
by changing the values ​​on Complex OSC Pitch, data is transmitted for a very short time.
The card also switches to WIFI onOFF mode during the tests on copitch.
The same USB cable has always been used.

Test.maxpat

join 3 @triggers 1
or triggers 2, no change

here is this to better understand each other.

The original patch is modified I would have had to say it at the beginning !!

ipcard.maxpat

here is this to better understand each other.
The original patch is modified I would have had to say it at the beginning !!

There is important thing to understand as very first thing.

Manufacturer of that card is not providing infos about osc strings, 

and no infos about which parameters really can be

I took it that each osc string which is published in Easel Max patches

 communication would also be usable as midi sysex messages

Only possibility is to test one after another.

As you have max 7, start sending parameters as sysex using that external

The fact that ipcformat produces some output, does not mean that message

would be accepted and translated to OSC and that card would react to it.

Screen Shot 2021-04-24 at 09.40.27.png

Here is modified Max Easel main patch with removed osc output,

but inserted ipcformat external and midiout, so that you can make test.

You can see the string which ipcformat sends.

ipcformat iprogramcard