Is it possible to use Objective-C to broadcast audio using the Icecast protocol?
For Node.JS I've found the library nicercast which seems to work pretty well. Is there an open-source equivalent for Objective-C or do I have to implement the protocol myself?
If I'll have to implement the protocol myself, then what do I need to know?
From the Node.JS Library I've seen that essentially, the server broadcasts an MPEG-stream using a normal web server and just sending the raw data over to the client.
Does this MPEG stream contain the metadata or do I have to send it separately?
Thanks in advance
Why not stream to an Icecast server instead? It's small enough to even run on embedded devices without big issues.
The nicercast implementation is nowhere close to being "Icecast compliant" as they claim.
If you want to know why, look at the Icecast sources or e.g. the supported formats.
I know it's en vogue to reinvent the wheel, badly and incompletely. But I'm at least going to remind you that it's not necessarily a good idea.
Related
I want to check if there is support for endianness(little endian/big endian) in plc4x modbus library to process the response based on that . I could not find any documentation or example on how to use if it exists.
So, request to same some links here if available.
Right now we currently don't support this, but we are aware of an option to fix this. Till now we haven't implemented any support for this mainly because none of our core contributors has access to such a Modbus device. If you have one particular device in mind, could you please name the Type an model or if you could provide us with such a device ... perhaps we can come up with an implementation.
Is it possible to use google protocol buffers as the serialisation mechanism when only one end of the comms channel is using it?
ie given a client that needs to speak to some 3rd party server or hardware that communicates in some defined message byte structure.
is it possible to specify the exact byte structure to expect using the protobuf IDL? Or does protobuf use it's own byte packing format therefore both ends must speak using protobuf protocol?
If not protobuf is there some library that would achieve this?
No. Protocol buffers has a very rigid layout, that cannot be changed, and is unlikely to match the one you are using unless it is secretly using protocol buffers and just not advertising that fact. The encoding is documented here.
As for alternatives; that would depend hugely on what platform / language / framework you are using. It would not be unusual to find you have to write your own tools for talking the required protocol.
I want to try and make my own application for my Novation Nocturn, which is a USB DJ controller surface. The application software interacts with it to send out MIDI messages to software like Traktor, Ableton and Cubase.
I'm aware of libusb, but that's as far as I've got. I've successfully installed it to interact with my device but stopped there.
I'm after some suitable reading material basically. USB specs, MIDI specs and such. If I'm honest the full USB 2.0 spec looks like it holds loads of stuff I don't need.
Just looking for something interesting to do now that I've finished my degree (Computer Science). My current programming knowledge is C++ and mainly C#.
Could do with some direction on how to get stuck into this task.
edit:
Update to include some info from the Device Manager on the Nocturn.
Hardware IDs:
USB\VID_1235&PID_000A&REV_0009
USB\VID_1235&PID_000A
Compatible IDs:
USB\Class_FF&SubClass_00&Prot_00
USB\Class_FF&SubClass_00
USB\Class_FF
Device Class:
MEDIA
USB MIDI is probably one abstraction layer lower than you want to deal with. I'd suggest finding a good MIDI framework and interacting with the device via MIDI instead.
For C++, Juce is probably the way to go, as you didn't mention a target platform or any other specific requirements.
If you want to go the .NET route, the easiest way to get started is with the C# MIDI Toolkit code:
http://www.codeproject.com/KB/audio-video/MIDIToolkit.aspx
In there, you'll find all the basics for opening an device, reading input, and writing output. Alternatively, NAudio has some MIDI classes, but they are somewhat incomplete.
As you develop, you'll want a reference for the MIDI spec handy.
A tool that you will find invaluable is MIDI-OX. In fact, I suggest that before you start coding, you fire up MIDI-OX and use it to sniff the messages coming from the Novation. It will give you a good idea of what the Novation sends. You can use it in conjunction with MIDI Yoke (a configurable virtual MIDI port) to insert itself between the Novation, and Ableton Live (or whatever software you normally use with your Novation) so you can see all of the messages in normal use.
Done... Kidding, but I've started on this in Python - I personally want linux support. I am teaching myself python, but I only dabble in programming.
You can see basic functionality at https://github.com/dewert/nocturn-linux-midi. The guy who reverse engineered it (i.e. the leap I wouldn't have been able to make myself) doesn't seem to be doing any more with it. His code is at https://github.com/timoahummel/nocturn-game
I am using PyPortMIDI and PyUSB, both of which I believe are wrappers for the C equivalents. I think this is all ok on Windows, but haven't tried.
What is currently on my github is crap, but it is proof-of-concept. I'm working on doing it properly now, with threading and proper configuration options.
The driver for the Nocturn makes it appear to system as a MIDI device, even though it isn't a USB MIDI device at the hardware level. The Automap software works entirely at the MIDI level, receiving MIDI instructions and sending different instructions in response - it is separate from the driver and not neccesary.
Alternatively, look at https://github.com/timoahummel/nocturn-game for an example of talking to it directly over USB from Python. You can probably port this to another language with libusb bindings.
Old thread, but I've just recently started looking into this.
I had a look at the Python application that dewert has written. Interestingly, it turns out that the data that the Nocturn emits is in fact MIDI, although it doesn't register itself as a USB MIDI device.
But looking at the actual data coming from the device, it actually emits control change messages (0xB0 controller value) for everything. Also the control commands that are sent to it are also control change messages, albeit only the data bytes, as the Nocturn seems to support MIDI running status (i.e. when sending multiple control change messages, it is not necessary to repeat the data byte).
Indeed, the looking at the magical initialization data it is actually just a bunch of control changes: it starts with 0xb0 and from there on the data comes in twos. For instance the last two bytes in the init string are 0x7f 0x00 which simply turn off the LED for the rightmost forward button. (There is something subtle happening as a result of the initialization being sent though, as the Nocturn sometimes emits some messages which appear to be some form of timeout events, and that behavior changes depending on whether the initialization string has been sent or not.)
Using MIDI-like messages makes sense, as Novation would be well aware of the MIDI protocol, so it would be easiest for them to use it for the communication even if the device is not strictly a MIDI device.
Note though that the incrementors just send the values 1 or 127, i.e. +1 or -1 step, so even with some trivial mapping software it's not really useful as it is. (Actually, if turned quickly, one can get 3 or 125 for instance, with the 125 corresponding to -3.) The only controller which sends a continuous value is the slider, which emits an 8 bit value when moved.
I suppose you'll want to know about USB classes in general and USB MIDI class in particular. The latter is the best what you can hope for in case you don't posess documentation for some proprietary protocol (whether it's used there instead).
I've been using MYNetwork by the venerable Jens Alfke for an app of mine that allows devices to connect and share info over the network, it's actually a mission-critical part of the app. I tried writing my own wrapper for all of the C-level stuff you have to do for Bonjour, but it didn't work out so well, so I moved to MYNetwork.
It's been great so far, but the fact it's essentially opaque to me is causing trouble, as is that I want to move over to ARC once we can submit apps with it (there's a lot of Objective-C object references in structs, which ARC hates).
Can anyone recommend a similar wrapper, ideally that allows easy message passing between a client and a server over Bonjour as well as service discovery?
Just a thought- Would using ZeroMQ advertised and discovered by the stock NSNetService suffice? Separating the service pub/sub from the actual communication would allow you to use other bonjour libraries like Avahi on linux too. ZeroMQ is sufficiently simple to make wrapping trivial, yet powerful enough to cope with complex network topologies, fast.
I have experience with both technologies in isolation but not together although I see no reason why it wouldn't work. The only caveat right now is the limited body of collective experience of ZeroMQ use on iOS but I'd expect that to change over time.
You know you can disable ARC for specific files? So, you can just disable ARC for the library, and keep it on for your other files.
Disable Automatic Reference Counting for Some Files
i'm newbie in FTP connection programming in Cocoa. I found 2 library that i can choose for make my app, but i dont know what's the best between these libraries. The libraries are libcurl and chilkat . The problem is what benefit of each library? Did somebody compare it? or maybe can anyone tell me about your experience? Thank you
I don't have any experience with chilkat, but I can tell yout that libcurl is used in a lot of programming languages and is available on a lot of systems. In for example PHP or on a Mac curl is a great tool to use.
So I would advice libcurl if it's available on your platform. You will probably find more information about curl and it has proven itself on many other platforms.
Also interesting if you want to go with curl is curlhandle. It's a cocoa wrapper around the curl library. Probably very handy in your case, but I've no experience with it.
I can tell you that the difference between libcurl and chilkat is like this: (though you probably know by now)
Chilkat is like the chess game you buy at the store and libcurl is like the plastic in liquid form you buy that you can make any chess piece with.
Libcurl is a slightly abstracted sockets-connector and Chilkat handles everything you'd do, up to a certain amount, with that connection. You're either staring at bits or something "made those bits into an email". I'm about to buy Chilkat for some of the libs, I like the features, but at the same time I wish I had time to read the RFC's and play with the other stuff using libcurl. Anywho, hope that answer is worth something to someone.
Because this question is still ranking high on google i give you my experience.
I bought chilkat in 2015 and moved to libcurl later and my own implementation much later. Both are far from perfect. libcurl just shows it's age and some weak designs.
libCurl is an library that tries to implement all URL able protocols even if they are designed as stream protocol like FTP. Do yourself a favour and only use it with HTTP/HTTPS. It just does the transfer part. Which is not enough for handling. You would love to see at least mime and charset routines to use the downloaded files.
Chilkat is a toplevel library that tries to give you as much highlevel access as possible. It uses background threads in script languages where it is not easy to use. The problem is that the API is terrible, very little documented and total failure when you want to write a quality program. For example it returns requests as a string. There is no way for stream processing. Now imagine you download a large GB iso file, you wont be happy. It can return as a file but then you have to specify this at the begin of a request when you don't knwo the download size.
Also the code quality until proven otherwise is bad. There are a few chilkat source code snippets in the wild which you can find via google and they are pure madness. Ok we don't know how this old code has been refactored now. But it leaves a bad taste, remember this is closed source and there is not a single mention about corner cases, which protocol is implemented, which feature of protocols are implemented and so on. You are using a total black box.
Also it does not allow high performance and high value code. I used it to write a web crawler and it was much much slower then libcurl.
I later used the HTTP and SSH compoenents to automate some server/client management scripts and there it shines. You know both sides and can just test if they work together and don't get any surprises. Then it is indeed easy and better then using the broken python or ruby SSH.
But if you ever contact with another unknown server, Chilkat is not your library.