you're right, set_history works on all inputs simultaneously. That's an architectural constraint; I don't think it would be /impossible/ to fix that, i.e. to make GNU Radio have different history per input buffer, but it's going to break API and therefore it's not going to be easy finding a good solution [1]. But unless you want to do upstream development (which is always welcome, by the way!), I'd recommend that you "emulate" additional history by overriding your block's forecast() method and telling GNU Radio that you need the additional number of items to produce a given amount of output; there's no obligation to always consume all your input.
I must admit that I can't really follow your coding scheme; that has nothing to do with your English (which is very good), but with the fact that I haven't ever heard anything about chaotic coding. At any rate, it might be helpful if you made a sketch of how your flow graph *should* look like, and put short descriptions what each stream transports in there. Best regards, Marcus [1] you need to have a vector of history lengths instead of a single integer; maybe Tom has some input on that. On 06/07/2015 08:29 PM, dcardona wrote: > Thank you very much Marcus. > > And to save the vectors in the third block, should i use the > set_history(n*2^n)? how do i set the input i want to save? because i have 2 > inputs > > > > -- > View this message in context: > http://gnuradio.4.n7.nabble.com/question-about-data-types-while-creating-blocks-tp54075p54081.html > Sent from the GnuRadio mailing list archive at Nabble.com. > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio