I would like to send a MIDI SysEx message like this to my Roland JX8P Synth.
F0 41 36 06 21 20 01 22 1B F7
This message would alter the VCF cutoff frequency of the synth. 1B is a variable hexadecimal value, swinging from 00 to 7F, relative to cutoff frequency.
In the MIDI library I've found the documentation for sending a SysEx message.
sendSysEx (int length, const byte *const array, bool ArrayContainsBoundaries=false)
From what I can tell bool ArrayContainsBoundaries specifies whether or not you want the library to include the F0 and F7 message start/stop tags (I don't so I'll set it to true). Int length denotes the message length in bytes(my message is 10 bytes, so this will be 10).
What I'm confused about is the array. Instead of storing all the values in the array can I just specify them like this?
MIDI.sendSysEx(10,0xF0 0x41 0x36 0x06 0x21 0x20 0x01 0x22 0x1B 0xF7,true);
Also, is adding the prefix 0x the correct way to specify the bytes here?
The basic answer is "no":
Your sendSysEx() function is looking for take two or three parameters:
Length
The array of data
The flag whether the array contains boundaries or not. This one is optional: if you omit it the parameter will be treated as false
By trying to pass your array data like this:
MIDI.sendSysEx(10,0xF0 0x41 0x36 0x06 0x21 0x20 0x01 0x22 0x1B 0xF7,true);
You are doing one of two things:
As written above, it is just a syntax error: the compiler doesn't know how to parse the list of numeric literals not separated by anything.
If you separated the items by a comma, the compiler says "Oh, he is passing 12 parameters. Let me look for a function that takes 12 integer parameters... oh, I don't have one. Sorry." That gives your no matching function for call to error.
So, one way to call your function is like this:
byte data[] = { 0xF0, 0x41, 0x36, 0x06, 0x21, 0x20, 0x01, 0x22, 0x1B, 0xF7 };
sendSysEx(10, data, true);
In C++11 you can get closer to what you want by initializing the list in the function call, something like sendSysEx(10,{0xF0, 0x41, 0x36, 0x06, 0x21, 0x20, 0x01, 0x22, 0x1B, 0xF7}, true);, however, you'll find that might run into another problem (depending on your toolchain): the compiler may assume that your initializer lists like that are lists of ints, not bytes, which will also cause a compiler error, unless you specifically told your compiler to assume integer literals to be 8 bits.
Related
I have found many topics that get me close to what I want to accomplish such as printf but out of a 1.7GB file I get a 12 byte output file. lol
Such as -
printf '%x\n' $(< input.txt) > output.txt
I have a large file containing 8 digit numbers.
01234567
Hex values: 0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37
I really want:
Hex values: 0x00, 0x01, 0x02, 0x03, 0x04, 0x04, 0x06, 0x07
input file and output file
Thank you!
There are a couple of python scripts...
By tinkering around, I found XOR 0x30 will get the results I want, ...
link
Changed the 0x71 to 0x30.
Also trying another script,
link
for k, the key, the last agrument, I entered 0 (which is 0x30) because I could not understand how to enter $'\x30' without an error.
With Qt 5.8.0.
This code runs as I expected.
static const char mydata[] = {
0x1, 0x2, 0x3, 0x4
};
QByteArray ba = QByteArray::fromRawData(mydata, sizeof(mydata));
const char *p = ba.constData();
const char *pp = QByteArray::fromRawData(mydata, sizeof(mydata)).constData();
qDebug("%p %p\n", p, pp);
output
0x40f548 0x40f548
dump
p 0x01 0x02 0x03 0x04
pp 0x01 0x02 0x03 0x04
But, I am struggling to understand what happens with this code after using data() instead of constData().
char *p = ba.data();
char *pp = QByteArray::fromRawData(mydata, sizeof(mydata)).data();
output
0x166941e8 0x166f8e70
dump
p 0x01 0x02 0x03 0x04
pp 0xee 0xfe 0xee 0xfe 0xee 0xfe ... (should be 0x01 0x02 0x03 0x04 ?)
As explained in Qt documentation, data() function gives you a deep copy of pointer to QByteArray data so every time that is called, it will gives you another value (different address).
While constData() gives you a read only pointer to main object so it value doesn't change on every time calling.
For more details you can check here for data() function description, and here for constData() description.
I am working with byte arrays and strings. I have a byte array that I modify and then use to generate a string. I have looked at lots of posts on this website that recommend using BlockCopy or System.Text.Encoding.Default.GetString(); I have tried those but for some reason the string I am getting has all gibberish characters.
Here is the problem and what i expect. Lets say i have hex encoded string of bytes as follows:
string str = "f20bdba6ff29eed7b046d1df9fb70000";
Corresponding array is:
byte[] arrayStr = new byte[] { 0xf2, 0x0b, 0xdb, 0xa6, 0xff, 0x29, 0xee, 0xd7, 0xb0, 0x46, 0xd1, 0xdf, 0x9f, 0xb7, 0x00, 0x00 };
Please note that 2 characters in above string represent byte.
Now, lets say I manipulate arrayStr and change the byte at array index 4 (0xff) to (0xe1). I want that I should be able to get a string such that:
string str = "f20bdba6e129eed7b046d1df9fb70000";
Look at BitConverter:
string str = BitConverter.ToString(arrayStr).Replace("-", "");
I just have a quick question about what this code mean. Sorry, been reading other posts but I couldn't fully grasp the concept since none seems to resemble this piece of code that I'm currently working in my embedded system.
int8u buf[1024];
memset(buf, 0, sizeof(buf));
*((int16u*)&buf[2]) = 0xbb01;
can someone explain to me what these lines mean?
It basically interprets the array of bytes buf as 16-bit words and then changes the second word to 0xbb01. Alternative representation:
int8u buf[1024];
memset(buf, 0, sizeof(buf));
int16u *words = buf;
buf[1] = 0xbb01;
&buf[2] takes the address to the second byte in buf. Then the cast to (int16u *) informs the compiler that the result is to be treated as a 16-bit unsigned integer. Finally, the memory on that address is set to 0xbb01.
Depending on the endianness of your system, the contents of buf could then be 0x00, 0x00, 0xbb, 0x01 or 0x00, 0x00, 0x01, 0xbb (followed by more NULs due to the memset()).
Please see the comment of the code for explanation
int8u buf[1024]; // intializing int array of size 1024 in RAM.
memset(buf, 0, sizeof(buf)); // fill in buffer with zero.
(int16u*)&buf[2] is a type casting for pointer which points to int16. here casting is given to &buf[2] i.e. address of buf[2].
*((int16u*)&buf[2]) = 0xbb01; // updating content of int16 -two byte intger starting at buf2
Why this is done ?
This is done as buf array was created is of int8u. and now we need to update int16 value 0xbb01. To do this, in above code we have created int16 pointer.
Step by Step simplification of above pointer
((int16u)&buf[2]) = 0xbb01;
updating content of ((int16u*)&buf[2]) by 0xbb01
&buf[2] is pointer to int16u and update its value by 0xbb01
update value at buf[2],buf[3] by 0xbb01.[#]
[#]: exact content of buf[2], buf[3] will depend on type of core architecture: big endian or small endian.
We have a pretty normal looking printf style function in our project, with the modification that the %g format means to print a GUID instead of the normal floating-point type. For our case, a GUID looks something like this:
struct guid {
uint32_t Data1;
uint16_t Data2;
uint16_t Data3;
uint8_t Data4[8];
};
In reality, the print function expects a pointer to the GUID to be passed, as opposed to the structure itself:
struct guid myGuid = { 0x867FD1E7, 0x9AA7, 0x472A, { 0xAA, 0x56, 0xF2, 0xDA, 0x66, 0x62, 0xCD, 0x4D } };
print("%g", &myGuid);
There are several places in the source base, however, where for some reason the entire guid is passed:
print("%g", myGuid);
This style of call seems to work fine with MSVC2003 - is there some ABI requirement that makes the compiler translate that function call style to actually pass a pointer behind the scenes? When porting this codebase to use clang/llvm, it certainly doesn't do the same thing.
Can somebody explain why the second version of the call works with MSVC? A pointer to the appropriate documentation would be much appreciated!
I think I found some clarification on MSDN:
Any argument that doesn’t fit in 8 bytes, or is not 1, 2, 4, or 8 bytes, must be passed by reference.
Looks like it's time to fix clang!