Shoot. Ok, I'll take a look too. I hope it's only a small thing messed up.
Glad I asked for people to check! (Second time now.)
enohp ym morf tnes
---
Dan Wilcox
danomatika.com
robotcowboy.com
> On Dec 4, 2017, at 8:43 PM, Miller Puckette wrote:
>
> Found it... should
Found it... should be fixed in git now.
cheers
M
On Mon, Dec 04, 2017 at 05:55:51PM +, Lucas Cordiviola wrote:
> But wait, there's a bug:
>
> when creating [notein] I play on my midichannel 1 and I get “145” on [notein]
> third outlet. 145 can't be a midichannel.
> Also when using
(probably because you need 5 bits to encode 1-16 vs 4 bits
> for 0-15). A lot of hardware that uses DIP switches or 7-segment digits to
> select channels uses 0-based counting, but software and equipment with
> decent displays uses 1-16. It seems that the user interface _should_
se
1-16 even though the underlying system uses 0-15.
Martin
> Ingo
>
>
>
> Subject: [PD] BUG on midifixes - (was: midifixes testing)
>
> But wait, there's a bug:
>
> when creating [notein] I play on my midichannel 1 and I get “145” on
> [notein] third
guess it's too late to change that in Pd without breaking everything ...)
Ingo
Subject: [PD] BUG on midifixes - (was: midifixes testing)
But wait, there's a bug:
when creating [notein] I play on my midichannel 1 and I get 145 on
[notein] third outlet. 145 can't be a midichannel.
Also when using
But wait, there's a bug:
when creating [notein] I play on my midichannel 1 and I get “145” on [notein]
third outlet. 145 can't be a midichannel.
Also when using [notein 1] I don't receive anything.
This is not happening on 0.48.0
ATM I cant test if this is also happening with [ctlin]
--