On Thu, May 12, 2016 at 9:18 AM, Marcus Müller
wrote:
> Yeah, like the head block, it's a copying operation. But that's
> "relatively cheap".
> I'm not quite sure about the state of this, but at GRCON '14 work was
> started on letting blocks define where their buffers are – maybe, one day,
> as
Yeah, like the head block, it's a copying operation. But that's
"relatively cheap".
I'm not quite sure about the state of this, but at GRCON '14 work was
started on letting blocks define where their buffers are – maybe, one
day, as a side effect, we can actually use the same buffers for in- and
out
If we wanted that behavior, could we do something similar to what gating
blocks do (like the power squelch), where we pass X number of items through
and after that only consume items without ever producing anything. Is there
an efficiency problem with this technique?
On Thu, May 12, 2016 at 6:14 A
Yep, having had a walk over this: if we didn't want to have this
behaviour, we'd need to have some buffer_writer specific done_policy or
so, where we tell the block it should shut down based on whether all or
just any one of its buffer readers signaled WORK_DONE.
We don't have that, so this is the
On Thu, May 12, 2016 at 5:13 AM, Marcus Müller
wrote:
> Yeah, I've been actually scratching my head on whether that is
> intentional or not – if we don't have that behaviour, there's no chance
> that a leaf in a non-path tree-shaped flow graph can stop the flow
> graph, is there?
Definitely in
Yeah, I've been actually scratching my head on whether that is
intentional or not – if we don't have that behaviour, there's no chance
that a leaf in a non-path tree-shaped flow graph can stop the flow
graph, is there?
On 12.05.2016 12:23, Sylvain Munaut wrote:
> Hi,
>
>
>> I thought so, too, at
Hi,
> I thought so, too, at first, but then tested:
>
> Null src +-> Head --> Null sink0
> \--> Null sink1
>
>
> stops.
>
> I think this is the "am done" message bubbling up from head to src, then
> src knowing it should be done, then the info "there's no input coming
> anymore"
I thought so, too, at first, but then tested:
Null src +-> Head --> Null sink0
\--> Null sink1
stops.
I think this is the "am done" message bubbling up from head to src, then
src knowing it should be done, then the info "there's no input coming
anymore" bubbling down to sink1.
Hi,
> I don't want the flowgraph to stop. I just want to store a set number but
> leave the flowgraph running.
The head block will only stop the flow graph if there is no other
active sinks that don't have a head block in front of them..
If there is other parts of the flow graph that can still c
Generate a general_block. Copy the content of head_impl.cc 's work()
method to the general_work method. don't forget the private variables
from head.h and the initialization of those in the constructor.
Replace the "return -1;" by "return 0" to make the block stop producing
samples after it's done
I don't want the flowgraph to stop. I just want to store a set number but
leave the flowgraph running.
On Wed, May 11, 2016 at 1:13 PM, Dan CaJacob wrote:
> You can use a head block inline (already in core).
>
> On Wed, May 11, 2016 at 4:09 PM Richard Bell
> wrote:
>
>> Hello,
>>
>> I want to a
You can use a head block inline (already in core).
On Wed, May 11, 2016 at 4:09 PM Richard Bell
wrote:
> Hello,
>
> I want to add an additional parameter to the existing file sink block that
> lets the user tell it how many items to save to file. This amounts to
> adding a few lines to the exist
Hello,
I want to add an additional parameter to the existing file sink block that
lets the user tell it how many items to save to file. This amounts to
adding a few lines to the existing file sink work function.
What's the smartest way to do this? What I would do currently is create a
new block,
13 matches
Mail list logo
