Jan, Yes you are right. I meant to say I don't have any commercial interest..
--A On Wed, Jul 15, 2015 at 1:57 PM, Jan Krämer <[email protected]> wrote: > Maybe OT and just for clarification, > > by putting your code on Github you essentially are distributing your work. > So licensing should concern you in that case. Still, Sylvain's answer on the > licensing issue should be correct. > > Cheers, > Jan > > > > 2015-07-15 13:47 GMT+02:00 Albin Stigö <[email protected]>: >> >> Hi Marcus, >> >> Thanks for your reply. >> >> This is just hacking for fun and I plan to put any code I produce on >> github so im not really concerned about licensing at the moment... >> >> The idea was to make the instrumentation blocks work well and native >> on mac... I was also looking into hacking the gnuradio-companion to >> work better on mac (it doesn't work well on retina displays). >> >> I will look into fifos! I was also thinking about some kind of shared >> memory IPC ringbuffer... >> >> --Albin >> >> On Wed, Jul 15, 2015 at 1:10 PM, Marcus Müller <[email protected]> >> wrote: >> > Hi Albin, >> > >> > GUI interaction is usually a bit tricky. Generally, GNU Radio is also >> > meant >> > to be used as a library that your main application uses for signal >> > processing, and you can get the raw samples in and out of your GNU Radio >> > flowgraph from any native application, but I don't really think that's >> > what >> > you'd start off with. >> > >> > If I had a recommendation: start off with the guided tutorials and the >> > Qt >> > visualizations in there. As a pretty easy, and in many cases performant >> > enough, solution, use sockets, named FIFOs or ZMQ sinks/sources to >> > exchange >> > data between your Cocoa (or whatever) application and your (headless) >> > GNU >> > Radio application, running as a separate process. That makes building, >> > modifying and debugging your signal processing separately from your GUI >> > much >> > easier, imho. >> > >> > By the way, I think there might be some licensing issues if you link >> > cocoa >> > code against GPL'ed code, but that's basically only relevant if you >> > start >> > selling/distributing your program; if you just use a communication >> > interface >> > (rather than dirtectly linking against GNU Radio) you'd have two >> > separate >> > programs, which would inherently solve the licensing problem (you'd only >> > need to guarantee your customers'/ software receivers' freedom to get, >> > modify and distribute the source code for the GPL program). >> > >> > Best regards, >> > Marcus >> > >> > >> > >> > On 15.07.2015 12:43, Albin Stigö wrote: >> >> >> >> Hi, >> >> >> >> I'm pretty new to gnuradio so please bear with me if I have missed >> >> something. >> >> >> >> I finally managed to get everything up and running on my macbook pro >> >> yesterday (with funcube dongle pro+) and experimented with building an >> >> out of tree block. >> >> >> >> I'm interested in writing some instrumentation blocks using native os >> >> x gui apis (cocoa and opengl). I was wondering if anyone has >> >> experimented with this..? The way cocoa works makes it a bit difficult >> >> to load a gui from dynamic library. I was thinking about starting >> >> another process from the block and then supplying it with data via >> >> some ipc mechanism... Has anyone done some work in this area? >> >> >> >> >> >> >> >> --Albin >> >> >> >> _______________________________________________ >> >> Discuss-gnuradio mailing list >> >> [email protected] >> >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> > >> > >> > >> > _______________________________________________ >> > Discuss-gnuradio mailing list >> > [email protected] >> > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> _______________________________________________ >> Discuss-gnuradio mailing list >> [email protected] >> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > _______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
