i think this sounds a bit like over-engineering in our case.
Where do you see over-engineering?
we almost have this scheme.
Maybe I was a bit too vague. Of course, contributors like you and me
already do this. I was rather suggesting that Miller himself would also
use feature branches instead
On 2/6/23 23:07, Christof Ressi wrote:
Afterwards, maybe current development can be in the branch until
ready, ie. feature/multi-channel or develop/0.54, etc?
That's what I would suggest in general.
It would be great if all new features, rewrites, experiments, etc. could
be made in feature
Afterwards, maybe current development can be in the branch until
ready, ie. feature/multi-channel or develop/0.54, etc?
That's what I would suggest in general.
It would be great if all new features, rewrites, experiments, etc. could
be made in feature branches. This has several advantages:
I'm fine with branching master, (hard) resetting back to a previous point,
merging/cherry-picking portaudio fixes, tagging 0.53-2, then doing a force
push. As long as everyone knows ahead of time, we can do a force pull
afterwards. Yes, it's best avoided, but is sometimes be needed.
That would be great a feature! I think many of us have thought about
that, but nobody has made a PR yet.
I think the easiest solution would be to add more options to [print]. I
particularly like the idea that [print] could (optionally) set the
containing abstraction as the error source.
You
Am 6. Februar 2023 21:24:54 MEZ schrieb Matt Barber :
>Hi dev list,
>
>Could there be a way to give abstractions the ability to raise pd_error()
>and highlight the abstraction instance with find last error? The reason for
>it would be that externals often distribute with a mix of binaries and
Hi dev list,
Could there be a way to give abstractions the ability to raise pd_error()
and highlight the abstraction instance with find last error? The reason for
it would be that externals often distribute with a mix of binaries and
abstractions, and it would be cool to have the user get an
On 2/6/23 00:38, IOhannes m zmölnig wrote:
On 2/5/23 22:56, Christof Ressi wrote:
it's compiling just fine here using mingw so it's probably something
stupid.
Are you building with ASIO support?
yes, that's crucial.
make sure you have ASIO extracted as asio/ASIO/
i've submitted a fix to
On 2/5/23 22:37, Miller Puckette via Pd-dev wrote:
Yep, I originally made a "0.53" branch but then messed it up so badly
I had to start over - and thought it better to change the name to
avoid confusion.
i see.
it seems like the "avoid confusion" did not utterly succeed though ;-)
in any
