Ok, sounds good, also I've only been updating cmake files, is there a date when the switch from autotools will become official?
~Andrew On Thu, Mar 8, 2012 at 5:56 PM, Tom Rondeau <t...@trondeau.com> wrote: > On Thu, Mar 8, 2012 at 5:40 PM, Andrew Davis <glneolistm...@gmail.com> > wrote: >> >> >As for the complex bandpass, we really do need that. I know I've used it >> > in GNU Radio-based projects before, and I'd bet >others have/are, too. >> > Creating it as an LPF and the frequency shifting it is a perfectly valid >> > way >> > of creating this kind of a >filter, and it enforces symmetrical transition >> > bands. >> >> OK, I have the code done It just uses different arguments, Instead of >> giving ignored lower transition band starts and stops, it just asks >> for the desired center. ( If again no one objects ) > > > So one thing to keep in mind is how we deal with changes in the API of the > code. Any time there is a change to an interface or arguments list (unless > it's a new argument with a default value at the end of the the list), it's > an API change, which means that it has to go into the 'next' branch. > > For this, since we're talking about removing the Python code and replacing > it with the C++ versions, it's probably safer to just say that this will go > into 'nex' and be a part of the 3.6 release. > > >> >> >If there's any way we can fix those bugs in the Python code, first, I'd >> > prefer to do that. >> >> If I can remember what they are, most problems didn't change the >> output though ( like unused, redundant, or improper code ). >> >> ~Andrew > > > If they didn't effect the output, no problem, but since it might slightly > here or there, it's just another reason to think about doing this on the > 'next' branch. > > This probably means that you don't have to do anything more, and I'm > assuming that you branched this off master initially. Since next is a > superset of master, the merge should be pretty easy and clean (conflicts > with autotools files, but that's expected). I'm just telling you this so you > understand how we thing about these things and making changes to the code. > > Thanks, > Tom > > >> >> On Thu, Mar 8, 2012 at 1:32 PM, Tom Rondeau <t...@trondeau.com> wrote: >> > On Thu, Mar 8, 2012 at 1:07 PM, Andrew Davis <glneolistm...@gmail.com> >> > wrote: >> >> >> >> Thanks, >> >> >> >> All the 'fix' comments are there as I was debugging on a remote >> >> machine using github as an intermediate for all my little changes. >> >> I'll get those merged into real comments before the real merge. Same >> >> for the AM demods, my github optfir branch is for my local testing and >> >> will only include optfir core in the merge to my master repo. I think >> >> I'll get the QA done over spring break ( next week ) along with more >> >> of blks2. >> > >> > >> > Ah, of course. I understand that mode of working. Not ideal, but >> > sometimes >> > necessary. I mistook the state of your branch. >> > >> >> >> >> Which brings me to a few questions, complex_band_pass appears to just >> >> be a complex shifted low pass and therefor does not actually do what >> >> it says it does ( the first band edge is only used to find the center >> >> frequency and not shape the actual band edge ), it is also not used >> >> anywhere ( except the filter design demo ), would anyone object if it >> >> was not included in the C++ version? Also I found a few small bugs in >> >> porting ( for instance 'desired_ampls = (0, 1)' I believe should have >> >> been 'desired_ampls = (0, gain)' ) so my version might not produce the >> >> exact same results in all cases but produce hopefully more correct >> >> taps. >> >> >> >> I figured float to be enough for any practical use, just a little >> >> venting in comments :) >> >> >> >> Now if only the FSF would get back with me...... >> >> >> >> ~Andrew >> > >> > >> > If there's any way we can fix those bugs in the Python code, first, I'd >> > prefer to do that. It'd be nice to make sure both worlds agree. >> > >> > As for the complex bandpass, we really do need that. I know I've used it >> > in >> > GNU Radio-based projects before, and I'd bet others have/are, too. >> > Creating >> > it as an LPF and the frequency shifting it is a perfectly valid way of >> > creating this kind of a filter, and it enforces symmetrical transition >> > bands. It might actually be nice to have a complex bandpass that fully >> > utilizes the PM algorithm to set the transition bands as desired on >> > either >> > ends, but that would only be useful for a special cases. >> > >> > Thanks, >> > Tom >> > >> > >> > >> >> >> >> On Thu, Mar 8, 2012 at 11:51 AM, Tom Rondeau <t...@trondeau.com> wrote: >> >> > Hi Andrew, >> >> > >> >> > Thanks again for taking the time to look into this. I have a few >> >> > comments. >> >> > >> >> > I was looking over your optfir branch and it needs a bit of work. >> >> > Commit >> >> > messages like 'fix' aren't helpful to the log and make figuring out >> >> > what >> >> > you >> >> > did confusing. Can you go through and squash these into single >> >> > commits >> >> > with >> >> > a more helpful commit message (take a look at our commit messages on >> >> > master >> >> > for what we're looking for). >> >> > >> >> > Also, it would be nice to only have this branch handle the optfir >> >> > conversion >> >> > and not have the AM demodulators in there as well. That can confuse >> >> > what's >> >> > going one, and it's easier to look at a branch merge that focuses on >> >> > doing >> >> > one thing. >> >> > >> >> > Is there any way that we can verify the results of the code? We don't >> >> > have >> >> > any QA code for the filter generators, but it should be easy enough >> >> > to >> >> > make >> >> > a set of known taps using optfir.py as our benchmark and then use the >> >> > same >> >> > parameters to see what the results from the C++ implementation are. >> >> > That'd >> >> > be a nice test so we can verify and prove that the new code works >> >> > well. >> >> > >> >> > I also noticed your comments on losing precision by casting to float. >> >> > I >> >> > wouldn't worry about that kind of precision since any amount of noise >> >> > is >> >> > going to ruin that for you, anyway. 32-bit floats is really more than >> >> > enough >> >> > for anything but the most extreme scientific tasks, and floats work a >> >> > hell >> >> > of a lot faster on almost any processor. >> >> > >> >> > Thanks again, >> >> > Tom >> >> > >> >> > >> >> > On Mon, Feb 27, 2012 at 1:11 PM, Tom Rondeau <t...@trondeau.com> >> >> > wrote: >> >> >> >> >> >> On Mon, Feb 27, 2012 at 1:01 PM, Andrew Davis >> >> >> <glneolistm...@gmail.com> >> >> >> wrote: >> >> >>> >> >> >>> >[Did you copy any files or text written by someone else in these >> >> >>> > changes? Even if that material is free software, we need to know >> >> >>> > about it.] >> >> >>> >> >> >>> Is this needed if I only copied from GNUradio, and if so, how would >> >> >>> I >> >> >>> reference optfir.py and firdes, by name or author? Or for the >> >> >>> request >> >> >>> do I only need to say yes? >> >> >>> >> >> >>> Thanks >> >> >> >> >> >> >> >> >> I'm never sure on these things. But they want this for their records >> >> >> and >> >> >> it doesn't obligate you to anything. Just write down something like >> >> >> "Yes, >> >> >> optfir.py and gr_firdes.cc from GNU Radio." That should be enough >> >> >> info >> >> >> for >> >> >> them. >> >> >> >> >> >> Thanks, >> >> >> Tom >> >> >> >> >> >> >> >> >> >> >> >>> >> >> >>> On Mon, Feb 27, 2012 at 11:11 AM, Tom Rondeau <t...@trondeau.com> >> >> >>> wrote: >> >> >>> > Hi Andrew, >> >> >>> > Now that you're contributing your work to us, we have to work out >> >> >>> > the >> >> >>> > annoying bureaucratic paperwork. All GNU Radio code gets its >> >> >>> > copyright >> >> >>> > assigned to the FSF, and so we need an agreement with you for >> >> >>> > this. >> >> >>> > I've >> >> >>> > attached the 'conditions.text' file to explain this to you more. >> >> >>> > >> >> >>> > Depending on how you want to go about this, you can either fill >> >> >>> > out >> >> >>> > the >> >> >>> > 'request-assign.changes' to cover these changes, or the >> >> >>> > 'request-assign.future' that will set you up for any future >> >> >>> > contributions to >> >> >>> > GNU Radio, as well. If you anticipate contributing work in the >> >> >>> > long >> >> >>> > run, the >> >> >>> > latter would be the best option for all of us, even if it does >> >> >>> > take >> >> >>> > a >> >> >>> > few >> >> >>> > weeks to turn it around. >> >> >>> > >> >> >>> > Thanks! >> >> >>> > Tom >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> > On Mon, Feb 27, 2012 at 11:03 AM, Tom Rondeau <t...@trondeau.com> >> >> >>> > wrote: >> >> >>> >> >> >> >>> >> On Fri, Feb 24, 2012 at 9:48 PM, Andrew Davis >> >> >>> >> <glneolistm...@gmail.com> >> >> >>> >> wrote: >> >> >>> >>> >> >> >>> >>> Ok, I've got a branch on github: >> >> >>> >>> https://github.com/glneo/gnuradio-davisaf/tree/optfir with >> >> >>> >>> optfir >> >> >>> >>> ported and working in C++, it's part of gr ( gr.optfir ) like >> >> >>> >>> firdes. >> >> >>> >>> This keeps the filter design tools together and allows the old >> >> >>> >>> optfir >> >> >>> >>> to still be imported and used until I can get all the examples >> >> >>> >>> ported >> >> >>> >>> ( which will just be changing "optfir" to "gr.optfir" ) >> >> >>> >>> >> >> >>> >>> This is kinda just an update, it will probably not be ready for >> >> >>> >>> merging until I finish porting the blks2 hier to C++. Then all >> >> >>> >>> the >> >> >>> >>> examples can be done in both python and C++, hopefully this >> >> >>> >>> opens >> >> >>> >>> up >> >> >>> >>> the API a bit. >> >> >>> >> >> >> >>> >> >> >> >>> >> Andrew, >> >> >>> >> Thanks. It might be easier to handle these in stages from a >> >> >>> >> merge >> >> >>> >> standpoint. Since you're just adding stuff, it's easy to add >> >> >>> >> bits >> >> >>> >> and >> >> >>> >> pieces. If the optfir is ready, we can look into merging it >> >> >>> >> while >> >> >>> >> you >> >> >>> >> make >> >> >>> >> another branch for other conversions to C++. >> >> >>> >> >> >> >>> >> Thanks! >> >> >>> >> Tom >> >> >>> >> >> >> >>> >> >> >> >>> >>> >> >> >>> >>> On Wed, Feb 8, 2012 at 11:27 PM, Andrew Davis >> >> >>> >>> <glneolistm...@gmail.com> >> >> >>> >>> wrote: >> >> >>> >>> > Thanks, I think i'll work on QA too while i'm at it then. >> >> >>> >>> > >> >> >>> >>> > >> >> >>> >>> > On Wed, Feb 8, 2012 at 10:32 PM, Tom Rondeau >> >> >>> >>> > <t...@trondeau.com> >> >> >>> >>> > wrote: >> >> >>> >>> >> >> >> >>> >>> >> On Tue, Feb 7, 2012 at 9:52 PM, Andrew Davis >> >> >>> >>> >> <glneolistm...@gmail.com> >> >> >>> >>> >> wrote: >> >> >>> >>> >>> >> >> >>> >>> >>> Hello all, >> >> >>> >>> >>> >> >> >>> >>> >>> I would like to help expand the C++ API, so I'm attempting >> >> >>> >>> >>> to >> >> >>> >>> >>> work on >> >> >>> >>> >>> Feature #394 or "Re-implement hierarchical blocks currently >> >> >>> >>> >>> living in >> >> >>> >>> >>> blks2 >> >> >>> >>> >>> in C++ and put into gnuradio-core/src/lib/hier." I've >> >> >>> >>> >>> started >> >> >>> >>> >>> on >> >> >>> >>> >>> am_demod.py >> >> >>> >>> >>> but this requires optfir, which is also in python, I think >> >> >>> >>> >>> this >> >> >>> >>> >>> should also >> >> >>> >>> >>> be available to us C++ users, so i'm converting it too. >> >> >>> >>> >>> I'm >> >> >>> >>> >>> new >> >> >>> >>> >>> to >> >> >>> >>> >>> GnuRadio >> >> >>> >>> >>> and would like to know if i'm on the right track before I >> >> >>> >>> >>> get >> >> >>> >>> >>> to >> >> >>> >>> >>> far. >> >> >>> >>> >>> The >> >> >>> >>> >>> files so far are included. >> >> >>> >>> >>> >> >> >>> >>> >>> Thank you. >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> >>> >> >> >> >>> >>> >> Hi Andrew, >> >> >>> >>> >> It looks to me like you're on the right track! Thanks for >> >> >>> >>> >> making a >> >> >>> >>> >> go >> >> >>> >>> >> at >> >> >>> >>> >> it. >> >> >>> >>> >> >> >> >>> >>> >> So you seem to have the general style correct in the files >> >> >>> >>> >> that >> >> >>> >>> >> I >> >> >>> >>> >> looked >> >> >>> >>> >> at. Once it's coded, the ultimate test is, obviously, to >> >> >>> >>> >> make >> >> >>> >>> >> sure >> >> >>> >>> >> that the >> >> >>> >>> >> data produced by any of these guys is the same as is >> >> >>> >>> >> produced >> >> >>> >>> >> by >> >> >>> >>> >> the >> >> >>> >>> >> Python >> >> >>> >>> >> versions. This is a good case where the QA code would be >> >> >>> >>> >> useful, >> >> >>> >>> >> so we >> >> >>> >>> >> would >> >> >>> >>> >> have a set of tests with known output that you could compare >> >> >>> >>> >> against >> >> >>> >>> >> the new >> >> >>> >>> >> implementations. Unfortunately, I don't see an QA for the >> >> >>> >>> >> optfir, >> >> >>> >>> >> but >> >> >>> >>> >> it >> >> >>> >>> >> would probably be good to have one. >> >> >>> >>> >> >> >> >>> >>> >> Tom >> >> >>> >>> >> >> >> >>> >>> > >> >> >>> >> >> >> >>> >> >> >> >>> > >> >> >> >> >> >> >> >> > >> > >> > > > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio