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 / 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.
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.
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.
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.
but maybe you are lookin for different ones ?
https://github.com/hideakitai/ArduinoOSC
same name , different content...
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.
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!
Pending a possible solution
Best regards
a new question?
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
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.
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,
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
So we have 3 changeable values
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.
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 !
Here is confirmed SYSEX LIST :
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.
Example:
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.
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
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
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
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 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.
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.
The same USB cable has always been used.
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 !!
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
sent using that ipcformat external.
I took it that each osc string which is published in Easel Max patches
which are for WiFi communication would also be usable as midi sysex messages
using that external.
That does not have to be true.
Only possibility is to test one after another.
As you have max 7, start sending parameters as sysex using that external
to card to see which do really work.
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.
Have a look at this :
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.
Reuploaded - fixed subpatch bpat_EG /sw_eg_trigger $1
One thing definitely does not work - naming the presets
because that external accepts symbol only at the beginning of the message,
following items must be ints or floats.
So message
will not work.
----------
Next thing is that you need to better understand messages in Max,
and usage of changeable argument signs ($1 $2 $3 etc ), to stop making mistakes.
The reason why program change does not work could be because:
1- maybe it is not possible at all to send it via midi
2- even if it is possible , you are doing it wrong !
3- I made a mistake capturing that and few other strings,
did not think about speed limit, so I reuploaded confirmed SYSEX List.txt
Please use SYSEX-LIST-OK.txt file which I uploaded instead of
original one with mistakes.
Look at what I posted for sysex messages that only use one changeable argument.
I posted example for save.
look just under the uploaded SYSEX-LIST-OK.txt
Is it so difficult to adapt that for load message ?
240 20 47 112 115 95 115 97 118 101 0 0 0 0 44 105 0 0 0 0 0 $1 247
-----------
Then - Easel patches have speedlim 20 which significantly reduces speed of sent messages
and also drops messages which get received faster then set limit.
Maybe they programmed that stuff so badly,
that it capitulates after having received few fader movements ???
Under sysexlist-ok I haven't seen the patch above?
I have tested all the main functions and everything is OK the keyboard works too.
Before asking the question here I haven't had time to test cv-connect which is to replace the patch yet.
for backups it's a bit long and it takes time it's a different approach than the application.
I accidentally deleted a patch again I loaded it through the app.
The recording mode seems to work and must be observed.
This mode seems to detail all the parameters to be saved for the creation of the patch to be saved so on max it is also possible but I have not tried everything correctly.
Speedlim solved the issues because on max 7 too it was complicated but the data is transmitted so that the card works without errors.
On max8 the concerns persist speedlim 20 connected at noon.
I have to ask for the midi implementation and architecture of this card, hoping to receive this document soon.
The Programm changes operation on max7.
Everything should work on max8 but without having the details of this card it is frankly very complicated.
I don’t understand why it wasn’t possible to reproduce ipcformat on max 8 but for me it’s programming and I’m not an expert developer.
With this additional information it's also very good!
I don't understand this line :
"On max8 the concerns persist speedlim 20 connected at noon."
Are you using google translate ?
Here is example for save and should be adapted for load,
replacing the sysex string for the load.
Problem with compiling that external is that all dependencies
(OSC Libraries) are outdated and should be rewritten for max sdk 8
as well as source cpp file itself.
I think that using extracted sysex messages would be as efficient
as that external.
------
Full wifi communication with the card is not only possible
with that iPad app.
One should be able to use all that functions in Max using udpsend and receive.
It would be just a matter to capture all the messages from/to the app and card,
to make exactly same editor as on iPad.
--------
One more thing - if you feel that 3 decimal places float precision
is not enough for connect parameter, I'll post the java code to
replace the coll with captured values.
Not having the notion of time to compile this external for maxsdk8 and obsolescence remains a major concern.
This application adds virtual wiring functions on these elements: / sw_co_timbre $ 1, / fd_eg_a $, / fd_eg_s $ 1, / fd_eg_d $ 1.
The precision of the decimals on the Easel MIDI-ipcformat patch is all functional on Max7 and 8.
With the use of UDP_S_R gave me the possibility to find a solution to switch to Max8.
While using ipcformat on max7.
It is max 7 which ensures the faulty communication on max8 which ensures the addressing.
On future computers and OSX ipcformat will be completely obsolete.
Here is the request to the developer of this card:
Please return the IMPLEMENTATION SHEET to me quickly.
Which includes all the transmission and reception characteristics of IPROGRAMCARD.
It is important to fully understand these missing explanations.
this is to know exactly the capabilities of this IPCARD and its ability to communicate with Max8.
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 sent using that ipcformat external.
Yes I use google translate
Thanks for these tips !!
Best regards
many options are possible such as wifi.
but I still use a USB connectionMany
here is the additional information received according to the questions sent, it would seem that it is incomplete:
It is all 8-bit Sysex messages
The messages formats should be made clear in the code.
You can only control the 1) virtual positions of faders, 2) virtual position of the switches 3) the connections of the virtual banana cables. That is all.
The software on the card takes care of everything else by interacting with the hardware of the 208.
Thanks for the help over the last few days, it's very helpful!
Between Max7 and Max 8 on the transfer of MIDI data is it different?
Thanks for your help
There was allways one difference between older and newer Max versions -
older are almost allways more efficient.
Try folowing :
1 enable overdrive
2 open Max preferences an set this values
3 disable any debugging or probe taking
If you are running Max on MacOS get info on Max.app
and set it to work in low resolution
In dsp status start with this settings for Performance and Scheduler
-----------
Don't try to use max 8 and max 7 at same time to send midi to the card
---------
But at the end this is sad truth : sysex messages are not high priority midi messages
and are not meant for realtime control also because the messages are in comparison to simple CC# change toooo long.
If you only want to send one value with the fader, insert mousefilter
between slider and midiout.
I overlooked one important thing - that ipcformat external is NOT
following sysex rules, that start 240 and end 247 bytes are only 8bit
values and all other 7bit or max 0 - 127.
What happens is that if one sends slider value > 127 and reaches
240 or 247 sysex is broken.
one would have to use / 128 and & 128 instead of
/ 256 and & 256 which ipcformat external is doing.
I don't understand how could developer do this.
It would be interesting to look at the source code of
the USB midi firmware implementation of that card.
---------
Max 7 and Max 8 react a bit different to bad sysex formatting .
Both would end sysex when 247 as value is hit, but Max 8 breaks the message
if 240 as value is hit before the end - 247, Max 7 does not.
Your only hope is that Card would react to 7 bit values.
But you will have to forget using float values.
I guess you don't really understand what I am talking about,
but let's put it in simple words : that ipcformat external is rubbish.
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.
I have indeed corrected it's perfect
to get same midiout behaviour as in Max 7 you could use imp.midi
https://www.theimpersonalstereo.com/s/impmidi_v1_0.zip
I tested it on Max 8.1.11 Mac and all sysex messages get sent out
without restrictions, even messages that make no sense or follow any midi rules,
as long as they remain in 0 -255 range.
Here is the patch to use
It does not need speedlim, but if you want to recall presets with many parameters, you must organise order of messages sent, don't send them all at once, but one after another.
---------
I am wondering why do you not use UDP WiFi instead of midi, even if there is no internet,
one can create adhoc network on any Mac or Win computer and
work with that without any internet connection.
And have access to all parameters.
Are you using Mac or Windows ?
The messages in 7 and 8 bits are indeed very different from where the loss of the decimals!
Notions of logic in electronics help me understand.
It's hard to get precise answers from the developer.
Is it possible to extract the USB source code from this card?
If so, you need to secure so as not to lose the data.
Questioning the developer remains possible, unfortunately without any certainty of answer!
Thank you for your important research.
The solution is to use imp.midi !!
I haven't used speelim, the actions are generally slow.
It’s true I have seen this rigorous organization.
Attached is a quick test.
I am on OSX so it is actually possible to use WIFI UDP what are the possibilities without having to deal with any interference?
It is true that it is more modern, but you have to be sure to manage WIFI data without loss.
Best regards
Imp midi seems to be working.
I haven't tried everything yet. record read I have to do it gradually
because from the start I focused on the basic parameters.
The theoretical aspect is not completely unknown to me but it is quite a long time ago, all this partially learned at a very young age.
I asked again about the source code and the firmware today because on Friday I received an email that did not correspond to the questions.
But know that your advice is very useful to me and I thank you very much!