System Exclusive MIDI messages can be of an arbitrary length, can csound's midiout opcode accomodate for that? Is there a workaround?
Csound's midiout supports only channel messages.
To get SysEx messages, you would have to use some external tool to convert some custom controller messages into SysEx messages. (See Send MIDI SysEx message based on CC or PC message, which has no answer; I don't know if midish would help, or if you'd have to write your own software.)
Related
I'd like to send RAW network packets from our Delphi application (XE3 to XE5, if important), but I can't find any info whatsoever about using PCap in Delphi at all.
How would one do that?
There is one Magenta library (sockmon and sockstat, monitoring and statistics library for observing raw incoming packets on selected interface), which works nice for receiving RAW packets, however there is no option to send RAW packets out.
Thanks.
Is there a way to drop a message on queue?
I receive my packet header and check some pattern on that, when that pattern fails I want to drop it. Is there a way for that? How to do that?
In rabbitMQ, messages are published on exchanges, and delivered to queues. You can configure a exchange that discards messages that fits some header patterns. Headers exchange. Or you can list a queue and ack a message that fits your pattern, without taking any further action, that is equivalent to drop message.
I have been working on a telnet/SSH app for the Windows Store and the telnet app has been receiving OOB data on its socket but I can't see it inside the app. I know this because the desktop version of the app is receiving OOB data. I also confirmed that the receive buffer in the Windows Store version is missing the one OOB data byte. In Wireshark I have confirmed that the OOB data is being received by the computer so its just not being forwarded to my app. I know in WinSock you need to set a special parameter to receive OOB data inline but I cannot find any such option for a Windows Store app. Does anyone know of a way to get this OOB data?
Another option would be to tell the telnet server to stop sending the OOB data. Is there to tell it to stop sending it?
For reference, the OOB data is being sent when pressing Ctrl+C. The OOB data byte is 0xFF and is the first byte sent by the server.
Thanks.
It appears that this functionality is not implemented in WinRT. Marking as answered.
http://social.msdn.microsoft.com/Forums/en-US/05a26a4b-e0db-4fed-b5d0-b67a2d9e2b1c/out-of-band-data-using-windowsnetworkingsockets?forum=winappswithnativecode
I'm researching the ability to send custom timestamped data events over RTP. An example might be a sequence of chat messages that should remain synchronized with whatever audio/video is being streamed. These messages have no intrinsic audio or video interpretation; it would be up to the client software to do something appropriate (add them to a chat log, etc).
I found some evidence that people accomplish this with a custom RTP codec. I also saw some talk of custom RTP payloads. Any light that can be shed here would be appreciated.
I would also be interested in hearing about possible implementations outside of RTP.
For transport of custom data per RTP it is probably best to use a custom unassigned payload type (see list at http://www.iana.org/assignments/rtp-parameters/rtp-parameters.xml). A more flexible approach would use a dynamic payload type assignment (ref, RFC 3551).
The sending side would set up the RTP header (ref. https://www.rfc-editor.org/rfc/rfc3550#section-5.1) with this payload type and the time stamp from the real time media frame you want to be in sync with.
On the receiving end you would dispatch handling of the RTP data based on the payload type in header of the received RTP packet. The handling should probably allow for little bit of latency between arrival of the media and the custom packet and then (dis)play both together ...
If you are working in Java, you can probably build your applciation based on the architecture and abstractions provided by the JMF (http://www.oracle.com/technetwork/java/javase/tech/index-jsp-140239.html).
I need to send a public key created by RSA by SMS to another phone.
I am converting the 148 byte public key to base64 to be sent by SMS. But it increases the 148 bytes to 200 bytes when converted.
As byte[] cannot be directly sent by SMS, what are the other possible methods of converting them successfully to strings or equivalent which can be sent through SMS? Other than compressing, is base64 the only possible method?
You can an SMS in 8bit mode - most GSM modems and gateways have this option, and some phones also expose this capability in their API.
This way you can send the entire key, and still have 12 bytes for extra data.
You'll need some software on the phone which will be able read the message and use it, though.
Another option: send it in two related separate SMSes; most(?) phones know how to send and combine separate SMSes to one logical message (to understand how it exactly works you'll have to dig into the SMS protocol specifications).
Adamk mentioned binary mode for sending SMS. Unfortunately this still leaves you with only 140 bytes for the payload, 8 bytes short!
If the target application is able to handle concatenated messages and it's acceptable that each key sent costs twice as much, then you should go with this solution.