I want to send MIDI notes using HEXA package.
G2, D♯3, D3
using coreMIDI in swift
please See below Midi Packet For above mention Note.
For G2
var packet1:MIDIPacket = MIDIPacket()
packet1.timeStamp = 0
packet1.length = 3
packet1.data.0 = 0x90 // Note On event channel 1
packet1.data.1 = 0x37 // Note C3
packet1.data.2 = 0x7F // Velocity
For D#3
just Update
packet1.data.1 = 0x3F
For D3
just Update
packet1.data.1 = 0x3E
For More Codes, Open this file MidiOutpout In Midi Monitor Application
Related
When pressing keys simultaneously (I experienced from 3 to 10 keys together ) , on Mac desktop using a piano connected via Bluetooth, it misses some notes. Maybe it is reproducible in iOS too but I haven't tried that out.
I am pretty sure it's a bug in with my Swift code because I used Midi monitor on the same mac simultaneously and Midi monitor finds all the note https://www.snoize.com/midimonitor/ but not CoreMIDI.
I also tried with a USB cable and with USB midi, but I can't reproduce.
Here is the Swift Code:
var client = MIDIClientRef()
var inputPort = MIDIPortRef()
MIDIClientCreate("MIDI Input Client" as CFString, nil, nil, &client)
MIDIInputPortCreate(client, "MIDI Input Port" as CFString, { (packetListPointer,_, _) in
let packets = packetListPointer.pointee
var packet = packets.packet
for _ in 0 ..< packets.numPackets {
let bytes = Mirror(reflecting: packet.data).children.map { $0.value }
// print("Received MIDI message: \(bytes)")
// Extract the relevant bytes from the MIDI message
let statusByte = Int(bytes[0] as! UInt8) // The status byte contains the message type
let noteByte = Int(bytes[1] as! UInt8)// The note byte contains the MIDI note number
// Check if the message is a note on or note off message
let isNoteOn = (statusByte & 0xF0) == 0x90 // The status byte for a note on message starts with 0x90
let isNoteOff = (statusByte & 0xF0) == 0x80 // The status byte for a note off message starts with 0x80
if isNoteOn || isNoteOff {
let noteNumber = Int(noteByte) // Convert the note byte to an integer
let noteName = NoteName(forNoteNumber: noteNumber)
let octave = noteNumber / 12 - 1 // Divide the note number by 12 and subtract 1 to get the octave
let direction = isNoteOn ? "up" : "down" // If it's a note on message, the direction is "up". If it's a note off message, the direction is "down"
print("Note: \(noteName)\(octave) \(direction)")
}
packet = MIDIPacketNext(&packet).pointee
}
}, nil, &inputPort)
// Set up the MIDI input endpoint and connect it to the input port
let sourceCount = MIDIGetNumberOfSources()
for i in 0..<sourceCount {
let src = MIDIGetSource(i)
MIDIPortConnectSource(inputPort, src, nil)
}
func NoteName(forNoteNumber noteNumber: Int) -> String {
let noteNames = ["C", "C#", "D", "D#", "E", "F", "F#", "G", "G#", "A", "A#", "B"]
let noteIndex = noteNumber % 12
return noteNames[noteIndex]
}
And this prints:
Note: B3 up
Note: A3 up
Note: E3 up
Note: G3 up
Note: F3 up
Note: E4 up
Note: F4 up
Note: D4 up
Note: G3 down
Note: A3 down
Note: F3 down
Note: E3 down
Note: B3 down
Note: D4 down
Note: E4 down
Note: C4 down
Note: G4 down
Note: F4 down
But the Midi Monitor prints:
19:58:58.510 From MIDI Piano Bluetooth Note On 1 B2 45
19:58:58.536 From MIDI Piano Bluetooth Note On 1 A2 70
19:58:58.536 From MIDI Piano Bluetooth Note On 1 E2 64
19:58:58.536 From MIDI Piano Bluetooth Note On 1 G2 70
19:58:58.536 From MIDI Piano Bluetooth Note On 1 F2 80
19:58:58.536 From MIDI Piano Bluetooth Note On 1 C3 43 <- missing
19:58:58.538 From MIDI Piano Bluetooth Note On 1 E3 64
19:58:58.538 From MIDI Piano Bluetooth Note On 1 F3 45 <- missing
19:58:58.538 From MIDI Piano Bluetooth Note On 1 G3 43
19:58:58.539 From MIDI Piano Bluetooth Note On 1 D3 47
19:58:58.780 From MIDI Piano Bluetooth Note Off 1 G2 0
19:58:58.807 From MIDI Piano Bluetooth Note Off 1 A2 0
19:58:58.807 From MIDI Piano Bluetooth Note Off 1 F2 0
19:58:58.807 From MIDI Piano Bluetooth Note Off 1 E2 0
19:58:58.807 From MIDI Piano Bluetooth Note Off 1 B2 0
19:58:58.808 From MIDI Piano Bluetooth Note Off 1 D3 0
19:58:58.808 From MIDI Piano Bluetooth Note Off 1 E3 0
19:58:58.817 From MIDI Piano Bluetooth Note Off 1 C3 0
19:58:58.817 From MIDI Piano Bluetooth Note Off 1 G3 0
19:58:58.818 From MIDI Piano Bluetooth Note Off 1 F3 0
(please ignore the octave shift of one)
I have some constraints like so:
interesting = 0x1
choked = 0x2
remote_interested = 0x4
remote_choked = 0x8
supports_extensions = 0x10
local_connection = 0x20
handshake = 0x40
connecting = 0x80
queued = 0x100
on_parole = 0x200
seed = 0x400
optimistic_unchoke = 0x800
rc4_encrypted = 0x100000
plaintext_encrypted = 0x200000
and the documentation tells me 'The flags attribute tells you in which state the peer is in. It is set to any combination of the enums above' so basically I call the dll and it fills in the structure with a decimal number representing the flag values, a few examples:
2086227
170
2098227
106
How do I from the decimal determine the flags?
In order to determine which flags were set, you need to use the bitwise AND operation (bit32.band() in Lua 5.2). For example:
function hasFlags(int, ...)
local all = bit32.bor(...)
return bit32.band(int, all) == all
end
if hasFlags(2086227, interesting, local_connection) then
-- do something that has interesting and local_connection
end
This is my first attempt at dpcu, I'm checking machine code generated by dpcu-16 assembly
I am using this emulator : http://dcpu.ru/
I am trying to compare code generated by
SET A, 0x1E
SET A, 0x1F
code generated is as follow :
fc01
7c01 001f
I don't get why operand size changes between those two values
That emulator appears to be using the next version of the DCPU-16 spec, which specifies that the same-word literal value for a permits values from 0xFFFF (-1) to 0x1E (30). This means that to get any literal value outside this range the assembler has to use the next-word literal syntax, which makes the operand one byte bigger.
0x1F (dec:31) is no longer a short literal (values -1 to 30), so it has to be read as a "next word" argument.
The opcodes are thus:
SET A, 0x1E
SET = 00001
A = 00000
1E = 111111
op = 1111110000000001 = fc01
SET A, 0x1F
SET = 00001
A = 00000
NW = 011111
op = 0111110000000001 = 7c01 + 001f
I want to write a player to play the music. I see the code like below:
AudioFileGetPropertyInfo(audioFile,
kAudioFilePropertyMagicCookieData, &size, nil);
if (size > 0) {
cookie = malloc(sizeof(char) * size);
AudioFileGetProperty(audioFile,
kAudioFilePropertyMagicCookieData, &size, cookie);
AudioQueueSetProperty(aduioQueue,
kAudioQueueProperty_MagicCookie, cookie, size);
free(cookie);
}
i don't know why to set the AudioQueueProperty,and what is the means about kAudioQueueProperty_MagicCookie? I can't find the help from the documentation.
who can give a direction to slove the problem.
Actually magic cookie is more than just a signature, it holds some information about the encoder, most useful items are "Maximum Bit Rate" and "Average Bit Rate", specially for a compressed format like AudioFileMPEG4Type. For this specific type magic cookie is same as "esds" box in MPEG-4 data file. You can find the exact bit settings at:
http://xhelmboyx.tripod.com/formats/mp4-layout.txt
8+ bytes vers. 2 ES Descriptor box
= long unsigned offset + long ASCII text string 'esds'
- if encoded to ISO/IEC 14496-10 AVC standards then optionally use:
= long unsigned offset + long ASCII text string 'm4ds'
-> 4 bytes version/flags = 8-bit hex version + 24-bit hex flags
(current = 0)
-> 1 byte ES descriptor type tag = 8-bit hex value 0x03
-> 3 bytes extended descriptor type tag string = 3 * 8-bit hex value
- types are Start = 0x80 ; End = 0xFE
- NOTE: the extended start tags may be left out
-> 1 byte descriptor type length = 8-bit unsigned length
-> 2 bytes ES ID = 16-bit unsigned value
-> 1 byte stream priority = 8-bit unsigned value
- Defaults to 16 and ranges from 0 through to 31
-> 1 byte decoder config descriptor type tag = 8-bit hex value 0x04
-> 3 bytes extended descriptor type tag string = 3 * 8-bit hex value
- types are Start = 0x80 ; End = 0xFE
- NOTE: the extended start tags may be left out
-> 1 byte descriptor type length = 8-bit unsigned length
-> 1 byte object type ID = 8-bit unsigned value
- type IDs are system v1 = 1 ; system v2 = 2
- type IDs are MPEG-4 video = 32 ; MPEG-4 AVC SPS = 33
- type IDs are MPEG-4 AVC PPS = 34 ; MPEG-4 audio = 64
- type IDs are MPEG-2 simple video = 96
- type IDs are MPEG-2 main video = 97
- type IDs are MPEG-2 SNR video = 98
- type IDs are MPEG-2 spatial video = 99
- type IDs are MPEG-2 high video = 100
- type IDs are MPEG-2 4:2:2 video = 101
- type IDs are MPEG-4 ADTS main = 102
- type IDs are MPEG-4 ADTS Low Complexity = 103
- type IDs are MPEG-4 ADTS Scalable Sampling Rate = 104
- type IDs are MPEG-2 ADTS = 105 ; MPEG-1 video = 106
- type IDs are MPEG-1 ADTS = 107 ; JPEG video = 108
- type IDs are private audio = 192 ; private video = 208
- type IDs are 16-bit PCM LE audio = 224 ; vorbis audio = 225
- type IDs are dolby v3 (AC3) audio = 226 ; alaw audio = 227
- type IDs are mulaw audio = 228 ; G723 ADPCM audio = 229
- type IDs are 16-bit PCM Big Endian audio = 230
- type IDs are Y'CbCr 4:2:0 (YV12) video = 240 ; H264 video = 241
- type IDs are H263 video = 242 ; H261 video = 243
-> 6 bits stream type = 3/4 byte hex value
- type IDs are object descript. = 1 ; clock ref. = 2
- type IDs are scene descript. = 4 ; visual = 4
- type IDs are audio = 5 ; MPEG-7 = 6 ; IPMP = 7
- type IDs are OCI = 8 ; MPEG Java = 9
- type IDs are user private = 32
-> 1 bit upstream flag = 1/8 byte hex value
-> 1 bit reserved flag = 1/8 byte hex value set to 1
-> 3 bytes buffer size = 24-bit unsigned value
-> 4 bytes maximum bit rate = 32-bit unsigned value
-> 4 bytes average bit rate = 32-bit unsigned value
-> 1 byte decoder specific descriptor type tag
= 8-bit hex value 0x05
-> 3 bytes extended descriptor type tag string
= 3 * 8-bit hex value
- types are Start = 0x80 ; End = 0xFE
- NOTE: the extended start tags may be left out
-> 1 byte descriptor type length
= 8-bit unsigned length
-> ES header start codes = hex dump
-> 1 byte SL config descriptor type tag = 8-bit hex value 0x06
-> 3 bytes extended descriptor type tag string = 3 * 8-bit hex value
- types are Start = 0x80 ; End = 0xFE
- NOTE: the extended start tags may be left out
-> 1 byte descriptor type length = 8-bit unsigned length
-> 1 byte SL value = 8-bit hex value set to 0x02
"
Magic Cookie that comes from kAudioFilePropertyMagicCookieData starts from ES Descriptor (just ignore the first 4 bytes described in the map and rest will be an exact match to magick cookie).
A sample magic cookie would be like this:
03 80 80 80 22 00 00 00 04 80 80 80 14 40 15 00 18 00 00 00 FA 00 00 00 FA 00 05 80 80 80 02 12 08 06 80 80 80 01 02
Maximum bit rate is at offset 18 -> 0XFA00 (or 64,000)
Average bit rate is at offset 22 -> 0XFA00 (or 64,000)
Although according to Apple documentation, magic cookie is read/write, but I had no chance changing the bit rate before creating or converting files.
Hope that helps someone.
The "magic cookie" is a file type signature consisting of a unique sequence of bytes at the beginning of the file, indicating the file format. The audio queue framework uses this information to determine how to decode or extract audio information from a file stream (instead of using or trusting the file name extension). The code you posted reads this set of bytes from the file, and passes it to the audio queue as a cookie. (It would be a mistake to let them be interpreted as PCM samples instead, for instance).
I am trying to create a software simulation on an Ubuntu GNU/Linux machine which will work like PPPoE. I would like this simulator to take outgoing packets, strip off the ethernet header, insert the PPP flags (7E, FF, 03, 00, and 21) and place the IP layer information in the PPP packet. I am having trouble with the FCS that goes after the data. From what I can tell, the cell modem I am using has a 2 byte FCS using the CRC16-CCITT method. I have found several pieces of software that will calculate this checksum, but none of them produce what is coming out the serial line (I have a serial line "sniffer" that shows me everything the modem is being sent).
I have been looking into the source of pppd and the linux kernel itself, and I can see that both of them have a method of adding an FCS to the data. It seems quite difficult to implement, as I have no experience in kernel hacking. Can someone come up with a simple way (preferably in Python) of calculating an FCS that matches the one that the kernel produces?
Thanks.
P.S. If anyone wants, I can add a sample of the data output I am getting to the serial modem.
Used simple python library crcmod.
import crcmod #pip3 install crcmod
fcsData = "A0 19 03 61 DC"
fcsData=''.join(fcsData.split(' '))
print(fcsData)
crc16 = crcmod.mkCrcFun(0x11021, rev=True,initCrc=0x0000, xorOut=0xFFFF)
print(hex(crc16(bytes.fromhex(fcsData))))
fcs=hex(crc16(bytes.fromhex(fcsData)))
I recently did something like this while testing code to kill a ppp connection ..
This worked for me:
# RFC 1662 Appendix C
def mkfcstab():
P = 0x8408
def valiter():
for b in range(256):
v = b
i = 8
while i:
v = (v >> 1) ^ P if v & 1 else v >> 1
i -= 1
yield v & 0xFFFF
return tuple(valiter())
fcstab = mkfcstab()
PPPINITFCS16 = 0xffff # Initial FCS value
PPPGOODFCS16 = 0xf0b8 # Good final FCS value
def pppfcs16(fcs, bytelist):
for b in bytelist:
fcs = (fcs >> 8) ^ fcstab[(fcs ^ b) & 0xff]
return fcs
To get the value:
fcs = pppfcs16(PPPINITFCS16, (ord(c) for c in frame)) ^ 0xFFFF
and swap the bytes (I used chr((fcs & 0xFF00) >> 8), chr(fcs & 0x00FF))
Got this from mbed.org PPP-Blinky:
// http://www.sunshine2k.de/coding/javascript/crc/crc_js.html - Correctly calculates
// the 16-bit FCS (crc) on our frames (Choose CRC16_CCITT_FALSE)
int crc;
void crcReset()
{
crc=0xffff; // crc restart
}
void crcDo(int x) // cumulative crc
{
for (int i=0; i<8; i++) {
crc=((crc&1)^(x&1))?(crc>>1)^0x8408:crc>>1; // crc calculator
x>>=1;
}
}
int crcBuf(char * buf, int size) // crc on an entire block of memory
{
crcReset();
for(int i=0; i<size; i++)crcDo(*buf++);
return crc;
}