Home

There are lots of changes on the way in GNU Radio. But since I don't think that I can say it better, here is Johnathan Corgan's email to the GNU Radio mailing list from yesterday describing it:

Some of you may have noticed recent check-ins that have added newtop-level components (like gr-fft), or duplication of blocks (such asinto gr-digital.) I'd like to explain the master plan Tom and I areworking from and what to expect over the next few weeks.

Essentially, we are making two things happen at the same time:

- libgnuradio-core is going away, and its blocks are being reorganizedinto several new, smaller libraries

These two transitions will occur in such a way that as much work aspossible will be completed on the master branch but without requiringany changes to your existing code, and the rest will happen on thenext branch.

The gnuradio-core component has accumulated hundreds of blocks overthe last 10 years. In order to simplify and organize things, we arecreating several new top-level components to replace it. The firststep of this was done when gr-digital collected much of the digitalmodulation/demodulation code up into its own component. The secondstep was to create gr-wavelet and move the wavelet blocks into that.When we are done, the following top-level components will hold all thecode that used to be in gnuradio-core:

* gnuradio-runtime - top block and friends and runtime scheduler, verysmall number of blocks for QA testing of runtime (vector source/sink,null source/sink, etc.)

The process we are following to get this done is to create the new toplevel components on the master branch and copy the existing blocksinto them, then remove the old blocks from gnuradio-core *on the nextbranch only*. In this way, developers can, if they wish, startmigrating their applications to use the new block hierarchy in theirapplications as they become available, without having to do it all atonce. Existing code, however, can also be left alone without anyimpact as gnuradio-core itself will remain unchanged until the 3.7release.

Part of this process is already done--gr-vocoder, gr-digital, andgr-wavelet are part of the current release. The new gr-fft was mergedinto master recently. Soon, gr-filter will be added in, and then wewill remove all fft and filter blocks out of gnuradio-core on the 3.7branch only. Today, several more blocks from gnuradio-core werecopied into gr-digital, and again, we'll soon delete those blocks outof gnuradio-core on the 3.7 branch only.

Since we're touching so much code, we're taking the opportunity make achange to the C++ API to implement pure virtual interface classes forAPI visible code. This was discussed on the mailing list March 12.In addition, we're reorganizing the API to use C++ namespaces, whichshortens filenames, simplifies the Python wrapper generation, andeliminates some redundancies in class naming. You can see an exampleof this in the new gr-fft directory on the master branch, or in thegr-wavelet directory on the next branch.

The same process for dividing the work between the master branch andnext branch applies here. Where possible, when we copy over blocksfrom gnuradio-core to the new top-level components, we'll convert themto use the new C++ coding style. This won't affect any existinguser's code, as the old blocks will stay in gnuradio-core. For allthe rest of GNU Radio outside of gnuradio-core, we'll be making theC++ changes on the next branch, again so as to not disturb existinguser's code.

Finally, during all this, as we implement the new block structure,we're going to pay special attention to:

Few of these changes will impact Python or GRC users, except that mostblocks that once lived in the 'gr' namespace imported from gnuradiowill instead import from a different namespace under gnuradio, such asis already done for gr-audio, gr-digital, gr-uhd, etc.

The net of all this is that we expect the 3.7 C++ API to be betterorganized, easier to use, and have better documentation, but withoutchanging much of the functionality other than performanceimprovements.

Tom and I will be working up documentation on the wiki detailing thechanges as we go along, and there will be a 3.6->3.7 conversion guidefor C++, Python, and GRC GNU Radio applications.