Re: [PD] [PD-announce] Pd 0.48-1 test version released

That one needs a lot more work... cheers M On Tue, Dec 05, 2017 at 12:36:25AM -0200, Alexandre Torres Porres wrote: > 2017-12-04 18:28 GMT-02:00 Miller Puckette : > > > This should fix or at least improve the spacing problems in 0.48-0 on > > macintosh computers > > > > It fixes it! And it loo

Re: [PD] [PD-announce] Pd 0.48-1 test version released

awesome! thanks again Miller. Fonts are looking lovely, and seems like the spacing is good. : ) ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

Re: [PD] [PD-announce] Pd 0.48-1 test version released

2017-12-04 18:28 GMT-02:00 Miller Puckette : > This should fix or at least improve the spacing problems in 0.48-0 on > macintosh computers > It fixes it! And it looks great! And I guess this also changes things a bit for the other operating systems, right? Anyway, what are other bug fixes we sho

Re: [PD] [PD-announce] Pd 0.48-1 test version released

thanks a lot Miller. will test this right now. for anyone else looking, here's the link to the download page: http://msp.ucsd.edu/software.html ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/lis

Re: [PD] midifixes testing

There is a fix for this: https://github.com/pure-data/pure-data/pull/263 > On Dec 4, 2017, at 11:16 PM, katja wrote: > > In pd 0.48-1test3 release on github (but called 0.48.1-1test2 in > 'About Pd') a [midiclkin] object still tries to instantia

Re: [PD] midifixes testing

In pd 0.48-1test3 release on github (but called 0.48.1-1test2 in 'About Pd') a [midiclkin] object still tries to instantiate in 'list of objects', that is, doc/5.reference. Katja On Mon, Dec 4, 2017 at 1:40 PM, Dan Wilcox wrote: > For MIDI heads out there who can build Pd, can y'all test the cur

[PD] [PD-announce] Pd 0.48-1 test version released

To pd-announce: Pd 0.48-1 is available in a first test version (0.48-1test3). This should fix or at least improve the spacing problems in 0.48-0 on macintosh computers, and contains many other bug fixes. With luck it will be possible for me to make the formal 0.48-1 release sometime next week.

Re: [PD] BUG on midifixes -

Oops... should be fixed now. On Mon, Dec 04, 2017 at 08:10:46PM +, Lucas Cordiviola wrote: > > Found it... should be fixed in git now. > > Seems to be OK now. (win32 with Christof's makefiles) > > but all midi activity gets printed on the console: > > status 144 > store status 144 > ... >

Re: [PD] BUG on midifixes -

The status prints are leftovers from debugging. They will be removed soon. Thanks for testing and finding this. It was a pretty simple thing I should have caught but did not as I was testing the midi objects mainly. I simply didn't test the actual channel message objects like [notein] first. Jus

Re: [PD] BUG on midifixes -

> Found it... should be fixed in git now. Seems to be OK now. (win32 with Christof's makefiles) but all midi activity gets printed on the console: status 144 store status 144 ... Mensaje telepatico asistido por maquinas. On 12/4/2017 4:52 PM, Dan Wilcox wrote: > Shoot. Ok, I'll take a look to

Re: [PD] BUG on midifixes - (was: midifixes testing)

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 be fixed in git

Re: [PD] BUG on midifixes - (was: midifixes testing)

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 [notein

Re: [PD] BUG on midifixes - (was: midifixes testing)

Wow, MIDI input doesn't work at all for me anymore... I'll try to figure out what's going on. thanks Miller On Mon, Dec 04, 2017 at 01:58:07PM -0500, Martin Peach wrote: > On Mon, Dec 4, 2017 at 1:39 PM, Ingo wrote: > > > 145 is the complete status byte for MIDI channel 2 note on. > > > > 144 s

Re: [PD] BUG on midifixes - (was: midifixes testing)

On Mon, Dec 4, 2017 at 1:39 PM, Ingo wrote: > 145 is the complete status byte for MIDI channel 2 note on. > > 144 should be subtracted but even then it still comes out to channel 2 > according to the MIDI specs and not 1. > Unfortunately the way Pd handles MIDI channels. > > The problem is that P

Re: [PD] BUG on midifixes - (was: midifixes testing)

145 is the complete status byte for MIDI channel 2 note on. 144 should be subtracted but even then it still comes out to channel 2 according to the MIDI specs and not 1. Unfortunately the way Pd handles MIDI channels. The problem is that Pd counts from 1-16 instead of 0-15. Maybe that's why it is

[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 [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] -- Men

Re: [PD] midifixes testing

I did a build for win32 using Christof's makefiles about 16hours ago. I used "doc/7.stuff/tools/miditester.pd" with a midi-cable loop on my soundcard's midi in/out Here's the console: /// sent channel: noteon 64 65 sent channel: noteon 66 0 sent channel: polytouch

Re: [PD] 0.47.1 tcl issue

no worries, can take it off list even if you want. ATSApplicationFontsPath font didn't help though. there must be something else. i'm in Japan and it's 2am, so that's it for me today, but happy to test anything to get this working perfect tomorrow. for the moment, at least all my existing patch

Re: [PD] 0.47.1 tcl issue

Sorry for all the back and forth. After all the work on the PR, I'd like to make *sure* we don't have any further issues for the next release. Thanks for testing. > On Dec 4, 2017, at 5:27 PM, Dan Wilcox wrote: > > It will work, you really just need to add > > ATSApplicationFontsPath > font >

Re: [PD] Force cyclone/gate instead of iemlib1/gate

2017-12-03 16:47 GMT-02:00 Alexandre Torres Porres : > I just think libname/objectname is easier and more explicit > Oh, it should be clear that doesn't work for a "-lib" You can actually allow that, and we made it so that you can actually load an object like [cyclone/>~], but that's another exc

Re: [PD] 0.47.1 tcl issue

It will work, you really just need to add ATSApplicationFontsPath font to the app's Info.plist. > On Dec 4, 2017, at 5:22 PM, Matt Davey wrote: > > ok, i had a go with copying the font folder, but still get that space to the > right. Dan Wilcox @danomatika

Re: [PD] 0.47.1 tcl issue

If the zeros have slashes, the sizing seems off since it's not using the right font. It should be fine with the next release. > On Dec 4, 2017, at 5:22 PM, Matt Davey wrote: > > ok, i had a go with copying the font folder, but still get that space to the > right. > > for the moment, that's m

Re: [PD] 0.47.1 tcl issue

ok, i had a go with copying the font folder, but still get that space to the right. for the moment, that's more than fine for my needs, and i have to get back to work, so thanks a lot for the help! i assume the new update is going to fix a lot of this anyway, and will be happy to help and report

Re: [PD] 0.47.1 tcl issue

Actually, you might as well just copy the Info.plist form 0.48 into 0.47 as well as there is also an entry which specifies the font directory. So yeah, you're getting into the nitty gritty of how the mac app bundle works. :) The template Info.plist is https://github.com/pure-data/pure-data/blob

Re: [PD] 0.47.1 tcl issue

[image: Inline image 1] On Tue, Dec 5, 2017 at 12:54 AM, Dan Wilcox wrote: > There are also a large number of screenshots from testing in the PR: > https://github.com/pure-data/pure-data/pull/227 > > On Dec 4, 2017, at 4:52 PM, Matt Davey wrote: > > ok, i tested furtherseems like any object

Re: [PD] 0.47.1 tcl issue

There are also a large number of screenshots from testing in the PR: https://github.com/pure-data/pure-data/pull/227 > On Dec 4, 2017, at 4:52 PM, Matt Davey wrote: > > ok, i tested furtherseems like any object with more than 3 characters i

Re: [PD] 0.47.1 tcl issue

ok, i tested furtherseems like any object with more than 3 characters in its name gets rendered with that space at the right. yeah, it very well could be the retina thing, as this is the first retina laptop i have had. will try that sizing test now

Re: [PD] 0.47.1 tcl issue

It might also be how the fonts are rendered on retina screens. You might just be used to how it was before. Can you send a screen shot of the sizing test showing what you mean? > On Dec 4, 2017, at 4:47 PM, Matt Davey wrote: > > from what i am seeing so far, those 0.48 and modified 0.47 builds

Re: [PD] 0.47.1 tcl issue

from what i am seeing so far, those 0.48 and modified 0.47 builds look exactly the same as far as font and object size goes. They both seem ok. i dunno why it seems there is an extra space to the right of objectsi have been using pd exclusively on desktop for the past few years, so maybe that'

Re: [PD] 0.47.1 tcl issue

I seem to remember you just got Pd 0.47-1 working on 10.13. Perhaps you can check that and the sizing build you downloaded ... :) > On Dec 4, 2017, at 4:29 PM, Matt Davey wrote: > > >There is a sizing test patch I added in docs/7.stuff/tools we can now use to > >compare object and UI sizes. Yo

Re: [PD] 0.47.1 tcl issue

...without a workaround, i mean ___ Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list

Re: [PD] 0.47.1 tcl issue

>There is a sizing test patch I added in docs/7.stuff/tools we can now use to compare object and UI sizes. You can do a before and after between different versions of Pd and compare. well, yeah, except that it seems now impossible to load old versions of PD on newest OSX On Tue, Dec 5, 2017 at 12

Re: [PD] 0.47.1 tcl issue

> On Dec 4, 2017, at 4:12 PM, Matt Davey wrote: > > one thing i'm noticing with all these new builds...there seems to be one > character of blank space to the right of every object and message box. Not sure what you mean. If you're talking about the font sizing being slightly different into

Re: [PD] 0.47.1 tcl issue

one thing i'm noticing with all these new builds...there seems to be one character of blank space to the right of every object and message box. is that intentional? pretty sure it didn't used to be that way. fonts on that .zip build you sent are working well, though...much closer to what i expec

Re: [PD] Force cyclone/gate instead of iemlib1/gate

> now, once i load the ZEXY library, there's no way to call VANILLA's > [wrap] anymore, it will always be ZEXY's version. you can still load the vanilla version with [wrap_aliased] after it has been overwritten. there's no way, however, to load [wrap] from another library (like [iemlib]) if it'

Re: [PD] Force cyclone/gate instead of iemlib1/gate

Christof Ressi wrote: True, but there are also exceptions, like in cyclone, and then there are oddities like iemlib being traditionally split into iemlib1 and iemlib2 - for whatever reason... :-) if this is a suggestion to join them into one IEMLIB library: here's my +1 ! =

Re: [PD] Force cyclone/gate instead of iemlib1/gate

> True, but there are also exceptions, like in cyclone, and then there are oddities like iemlib being traditionally split into iemlib1 and iemlib2 - for whatever reason... :-)     Gesendet: Montag, 04. Dezember 2017 um 14:06 Uhr Von: "Alexandre Torres Porres" An: "IOhannes m zmoelnig" Cc: "pd

Re: [PD] Force cyclone/gate instead of iemlib1/gate

my work around for organelle has been to remove the gate in iemlib completely iemlib is crucial for many things related to filter and modulo_counter gets a ton of use as well recently Patrick Pagano B.S, M.F.A Assistant Professor in Residence Digital Media & Design Web & Interactive Techno

Re: [PD] Force cyclone/gate instead of iemlib1/gate

2017-12-04 7:19 GMT-02:00 IOhannes m zmoelnig : > > > the only rule of thumb is to inspect the library folder, and if you see > many (or no) {dll|pd_darwin|pd_linux}s files you should use "-path", and > if there are only a very few (usually one(1)) with the name of the > library, then you should us

Re: [PD] Force cyclone/gate instead of iemlib1/gate

I dont know how pdmtl is structured, but you can always screw it up and wrap it in a way that doesn't work. Other than that, if you do things in a certain way, considered as "safe" / "correct" or "usual", that libname/objectname syntax will never be a problem. The way it works is that your lib nee

[PD] midifixes testing

For MIDI heads out there who can build Pd, can y'all test the current git master? My midifixes PR was merged into master and it would be good to get some testing on it. I developed a tool to test things which might be handy: https://github.com/

Re: [PD] 0.47.1 tcl issue

If you can, please test the sizing fixes. Here is a build I've been using the last month: Pd-0.48.0-sizingfixes.app.zip > On Dec 4, 2017, at 12:00 PM, Matt Davey wrote: > > awesome! thanks a lot Dan. > > i got my TCL versi

Re: [PD] 0.47.1 tcl issue

awesome! thanks a lot Dan. i got my TCL version by copying this into terminal: echo 'puts [info patchlevel];exit 0' | tclsh Even with the latest version of osx 10.13, downloaded last night, it still comes up as using 8.5.9, so the framework folder probably does need to be copied over. Your bull

Re: [PD] 0.47.1 tcl issue

> On Dec 4, 2017, at 10:19 AM, pd-list-requ...@lists.iem.at wrote: > > hi, just tried installing both the 32 and 64 bit vanilla builds on newly > updated macbook with OSX 10.13.1, and get error pasted below. > > so, i checked, and it seems this version of OSX only comes with tcl 8.5, > not 8.4.

Re: [PD] Force cyclone/gate instead of iemlib1/gate

On 2017-12-04 10:32, Roman Haefeli wrote: > > While I fully agree with you, I do believe you are actually helping > confuse users thanks for reminding me that i should at least have put on the "rant" tags. > by not providing an iemlib build for Linux. If there'd be > a canonical build (as oppos

Re: [PD] Camomile v0.1.0 - pre-release

Yes, it would be great. Thanks! (Sorry I didn't see it came from the pd-list also) I'll send new binaries for Windows via the Github issue. I guess 32bit version should be easy to do. The problem is to link Camomile with the libPd static library (libpd.lib) on Windows (so libpd will be integrated

Re: [PD] Force cyclone/gate instead of iemlib1/gate

On Mon, 2017-12-04 at 10:19 +0100, IOhannes m zmoelnig wrote: > On 2017-12-04 10:05, abel.jer...@free.fr wrote: > > > > Beyond the topic, I wonder also how to know if a library needs "- > > lib" option, and for which operating system. For iemlib, on Xubuntu > > the "-path" option is enough, on Win

Re: [PD] Force cyclone/gate instead of iemlib1/gate

On 2017-12-04 10:05, abel.jer...@free.fr wrote: > Beyond the topic, I wonder also how to know if a library needs "-lib" option, > and for which operating system. For iemlib, on Xubuntu the "-path" option is > enough, on Windows, I need to add "-lib". Hard to follow if it is not the > same option

Re: [PD] Force cyclone/gate instead of iemlib1/gate

Hi. Beyond the topic, I wonder also how to know if a library needs "-lib" option, and for which operating system. For iemlib, on Xubuntu the "-path" option is enough, on Windows, I need to add "-lib". Hard to follow if it is not the same option between platforms. > Now, with Pd Vanilla, you ca