[L2Ork-dev] Purr Data 2.15.0

Albert Graef aggraef at gmail.com
Sun Oct 11 16:06:09 EDT 2020


Hi Joseph,

Thanks for your patience, and sorry for replying so late.

On Sat, Oct 10, 2020 at 4:53 PM Linux ROUEN Normandie <linux.rouen at free.fr>
wrote:

> 1. Under GNU/Linux when in EditMode, Purr Data is becoming totally
> unresponsive as well as my whole system, even if other applications are
> still running well in the background and I can move my mouse cursor on the
> screen, your suggested Ctrl+Alt+F1-to-F6 have no effect at all.
>

Well, I guess that we'll just have to wait until someone can reproduce this
and tell us what the exact issue is (in case it's really related to Purr).

2. I cannot access to your
> https://download.opensuse.org/repositories/home:/aggraef:/purr-data-git/xUbuntu_20.04/amd64/purr-data_2.15.0+git4683+bf8ba131-1_amd64.deb
> for testing your nw.js 0.28.1 update.
>

The OBS doesn't keep old builds, and I keep updating the preview channel
all the time. So just go over to
https://build.opensuse.org/package/show/home:aggraef:purr-data-git/purr-data
instead, click the Download link on the top of that page, and proceed to
the download for Ubuntu (see the screenie below).

[image: image.png]
Currently, you'll find the 2.15.1 release candidate there. (Which will soon
be available in the main channel and on my GH mirror as well, as soon as
I'm done building the Windows packages.)

Best,
Albert


I'm getting the following message translated from French: "Error 404 - This
> resource doesn't exist anymore!".
>
> Thanks. Best,
> Joseph Gastelais
> - - - - - - - - - - - - - - - - - - - -
>
> Le 05/10/2020 à 09:35, Albert Graef a écrit :
>
> On Mon, Oct 5, 2020 at 3:40 AM Linux ROUEN Normandie <linux.rouen at free.fr>
> wrote:
>
>> But under LM20, the random freeze issues I'm reporting happen *ONLY* when
>> in *EditMode* and *WITHOUT* the JACK server running and with DSP=OFF!
>>
>
> That's weird. Is your LM20 box the only system where this happens? I agree
> with Ico's assertion that there's simply no way that Purr can take down an
> entire system like this. But there's a first time for everything...
>
> Next time please make sure that you're running htop so that you can see
> it, and check the cpu and ram usage when the freeze starts. (You can also
> try whether you can still switch to another Linux console and check cpu and
> ram usage there.) Here are some things to look out for:
>
> 1. If the ram usage is going through the roof, then your system might be
> well into swap memory, which can make it appear frozen. (In that case
> you'll probably notice that a lot of disk activity is going on as well.)
>
> 2. If the cpu usage is 100%, then there's a runaway process, and htop
> should tell you which one it is. "purr-data" means that it's the engine,
> "nw" means that it's the GUI, anything else we can figure out when you post
> the executable name here.
>
> 3. If both cpu and ram usage are normal, then keyboard and mouse might
> have been grabbed by some program or a modal dialog hiding beneath other
> windows, making your system unresponsive to input but still chugging along.
> In that case, try whether you can use something like Ctrl+Alt+F2 to change
> to another Linux console (yes, sometimes this will still work even if your
> system is unresponsive to all other keyboard input), log in from the
> console and run `sudo ps aux` to see which processes are running and
> whether you notice anything unusual there.
>
> For now, I will remain quiet on this subject until I found a reproducible
>> and documented procedure...
>>
>
> If you do, please open a new bug report on this and provide as much
> information as you can, thanks! My bet still is on a hardware or OS issue,
> but, as the German saying goes, "one has seen horses throw up in front of
> the pharmacy." ;-)
>
> Best,
> Albert
>
>
> - - - - - - - - - - - - - - - - - - - -
>> Best, Joseph Gastelais
>> - - - - - - - - - - - - - - - - - - - -
>>
>> Le 05/10/2020 à 00:54, Ivica Bukvic a écrit :
>>
>> Are you running a distro with rt privileges (e.g. using a low latency
>> kernel)? Are you running Purr-Data with rt privileges? If not, there is no
>> way Purr-Data is responsible for your hard locks. If you are running
>> rt/lowlatency kernel, as per Albert, you should monitor what you are
>> running and observe when these things happen. This will help narrow things
>> down.
>>
>> Best,
>>
>> Ico
>>
>> --
>> Ivica Ico Bukvic, D.M.A.
>> Director, Creativity + Innovation
>> Institute for Creativity, Arts, and Technology
>>
>> Virginia Tech
>> Creative Technologies in Music
>> School of Performing Arts – 0141
>> Blacksburg, VA 24061
>> (540) 231-6139
>> ico at vt.edu
>>
>> www.icat.vt.edu
>> www.performingarts.vt.edu
>> l2ork.icat.vt.edu
>> ico.bukvic.net
>>
>> On Sun, Oct 4, 2020, 17:42 Linux ROUEN Normandie <linux.rouen at free.fr>
>> wrote:
>>
>>> Hello Ico,
>>>
>>> I'm spending most (+95%) of my computer time on GNU/Linux and not
>>> Windows (this one is just for testing purpose as still the majority of the
>>> PC users are on this OS).
>>> Under Linux I never had BSOD but under Windows, even with the latest W10
>>> v2004, it's just an old friend of mine since W3.1! LOL
>>>
>>> When using Purr Data and my PC is totally freezing under Linux, my
>>> computer screen is still correctly displaying what it was doing. Even after
>>> ten minutes of total freeze I'm still and just able to move my mouse cursor
>>> but its clicks are inactive awa my keyboard. Moving my mouse over the icons
>>> of the System Dashboard normally displays information but in freeze state
>>> nothing at all. During addition tests, if other Audio and/or Video
>>> applications were running before total freeze, even if my PC became
>>> unresponsive these applications continue to run well (so neither Audio nor
>>> Video freeze). The only way I have for taking back the control of my PC is
>>> to force the shutdown of my computer with its On/Off button and I'm get
>>> nothing visible before closing.
>>>
>>> So, as I wrote one hour ago, one of the possibility is to record on disk
>>> the system activities to try to find out what could happen but this will
>>> depend of what was record just before the total freeze... Wait and see...
>>>
>>> - - - - - - - - - - - - - - - - - - - -
>>> Best, Joseph Gastelais
>>> - - - - - - - - - - - - - - - - - - - -
>>>
>>> Le 04/10/2020 à 20:14, Ivica Bukvic a écrit :
>>>
>>> To add to Albert's thorough email, I wonder if video acceleration in the
>>> chromium versions nw.js may be relying on may have something to do with
>>> this. Namely, I wonder if it invokes something incorrectly and/or the video
>>> driver is not handling such calls appropriately. If you get a blue screen
>>> dump before the computer reboots, it may be helpful to share that. The same
>>> may be also added to your system event log.
>>>
>>> Best,
>>>
>>> Ico
>>>
>>> --
>>> Ivica Ico Bukvic, D.M.A.
>>> Director, Creativity + Innovation
>>> Institute for Creativity, Arts, and Technology
>>>
>>> Virginia Tech
>>> Creative Technologies in Music
>>> School of Performing Arts – 0141
>>> Blacksburg, VA 24061
>>> (540) 231-6139
>>> ico at vt.edu
>>>
>>> www.icat.vt.edu
>>> www.performingarts.vt.edu
>>> l2ork.icat.vt.edu
>>> ico.bukvic.net
>>>
>>> On Sun, Oct 4, 2020, 07:50 Albert Graef <aggraef at gmail.com> wrote:
>>>
>>>> Hi Joseph,
>>>>
>>>> there's a Windows package with Ico's fix here:
>>>> https://git.purrdata.net/jwilkes/purr-data/-/jobs/22210
>>>>
>>>> A new release including this and a few other fixes will hopefully be
>>>> out sometime next week.
>>>>
>>>> Also, I'm currently testing an update to nw.js 0.28.1 (which fixes
>>>> issues with the floating dialogs for some graphics cards under Windows). I
>>>> doubt that this will cure your performance issues under Linux, but you
>>>> never know until you've tried. ;-) If you want to give it a go, this is now
>>>> available in the OBS preview channel; the Ubuntu 20.04 package is at:
>>>> https://download.opensuse.org/repositories/home:/aggraef:/purr-data-git/xUbuntu_20.04/amd64/purr-data_2.15.0+git4683+bf8ba131-1_amd64.deb
>>>>
>>>> I do need to find *a reproducible test procedure* which could record
>>>>> what is going wrong when both Purr Data and my PC are totally freezing.
>>>>>
>>>>
>>>> If your *entire system* is freezing and not just Purr Data, I'm
>>>> beginning to wonder whether some hardware issue or some runaway process
>>>> might be the root cause. It could be a faulty hardware component (RAM,
>>>> harddisk, soundcard, usb peripherals, ...), or some driver misbehaving for
>>>> old components that aren't properly supported any longer. That rarely
>>>> happens in Linux, though, and in that case you'd probably see it with other
>>>> demanding applications, too.
>>>>
>>>> Anyway, as you rightfully remarked, the first step in diagnosing such a
>>>> problem would be to identify characteristics of situations in which these
>>>> hiccups occur, such as heavy disk/usb/network/audio/graphics operations, or
>>>> abnormally high CPU or RAM usage, and which applications and background
>>>> jobs are running at the time. A monitoring program like htop should help to
>>>> identify these, but you surely know this already. The venerable gkrellm (
>>>> http://gkrellm.srcbox.net/) is another monitoring tool that I find so
>>>> indispensable for checking system health a glance, that I use it not only
>>>> on Linux, but on all of my Windows boxes, too. (Unfortunately, gkrellm
>>>> hasn't been ported to macOS, as far as I know. But there's a similar
>>>> open-source tool named XRG there, see
>>>> https://gaucho.software/Products/XRG/.)
>>>>
>>>> In particular, some desktop environments have integrated file indexing
>>>> facilities which are notorious for sucking up system resources, especially
>>>> on older and slower hardware. Some of these can be disabled easily, while
>>>> others keep coming back like the undead after each boot, login, or even on
>>>> their own. I've even noticed this on newer hardware, that's why until very
>>>> recently I sometimes had to suspend Baloo (KDE's indexer) when I'm in a
>>>> live video session running some heavy-duty realtime apps such as Ardour,
>>>> OBS Studio and Jitsi Meet at the same time (Purr is usually the lightest
>>>> among these...). On older hardware, these may well bring your system down
>>>> to its knees.
>>>>
>>>> Have a nice Sunday,
>>>> Albert
>>>>
>>>>
>>>>
>>>> On Sun, Oct 4, 2020 at 12:02 PM Linux ROUEN Normandie <
>>>> linux.rouen at free.fr> wrote:
>>>>
>>>>> @Ico,
>>>>>
>>>>> Great! Thanks for your Windows fix.
>>>>> - - - - - - - - - - - -
>>>>> Joseph Gastelais
>>>>> - - - - - - - - - - - -
>>>>>
>>>>> Le 03/10/2020 à 19:31, Ivica Bukvic a écrit :
>>>>>
>>>>> The window size is already fixed in the new merge request. The problem
>>>>> was Windows up until now used nw.js 0.14.7 which had a bug in respect to
>>>>> the window size. I did a patch to compensate for that. Now that needs to be
>>>>> removed since Windows has migrated to 0.24.4. That should be included in
>>>>> the next release since the merge request is already green. Hope this helps.
>>>>>
>>>>> Best,
>>>>>
>>>>> Ico
>>>>>
>>>>> --
>>>>> Ivica Ico Bukvic, D.M.A.
>>>>> Director, Creativity + Innovation
>>>>> Institute for Creativity, Arts, and Technology
>>>>>
>>>>> Virginia Tech
>>>>> Creative Technologies in Music
>>>>> School of Performing Arts – 0141
>>>>> Blacksburg, VA 24061
>>>>> (540) 231-6139
>>>>> ico at vt.edu
>>>>>
>>>>> www.icat.vt.edu
>>>>> www.performingarts.vt.edu
>>>>> l2ork.icat.vt.edu
>>>>> ico.bukvic.net
>>>>>
>>>>> On Sat, Oct 3, 2020, 13:19 Linux ROUEN Normandie <linux.rouen at free.fr>
>>>>> wrote:
>>>>>
>>>>>> Hello Albert,
>>>>>>
>>>>>> Thanks for your comments.
>>>>>>
>>>>>> 1. Zoom level
>>>>>> After additional new tests, I discovered *my Mistake* :-( as under
>>>>>> GNU/Linux I'm using a screen scale of x1 and under Windows a screen scale
>>>>>> of x1.25! Windows with a screen scale of x1 gives almost the same results
>>>>>> than under the Linuxes. :-)
>>>>>>
>>>>>> 2. But there are still some visible differences between Linux and
>>>>>> Windows graphics rendering. See the 3 attached files for the Control Panel
>>>>>> of my SMS project awa for the windows of Canvas Help and Canvas Properties.
>>>>>> Under both OSs I'm using a screen resolution of 1920x1080, and now a screen
>>>>>> scale of x1.
>>>>>>
>>>>>> 3. Random freezes under GNU/Linux
>>>>>> I do need to find *a reproducible test procedure* which could record
>>>>>> what is going wrong when both Purr Data and my PC are totally freezing. As
>>>>>> it's on a random basis, it can really occur for what ever I'm doing (Edit
>>>>>> Mode). So, for the time being I'm dry.
>>>>>> If anyone has any clever idea, you are the welcome.
>>>>>>
>>>>>> - - - - - - - - - - - - - - - - - - - -
>>>>>> Best, Joseph Gastelais
>>>>>> - - - - - - - - - - - - - - - - - - - -
>>>>>>
>>>>>> Le 03/10/2020 à 08:21, Albert Graef a écrit :
>>>>>>
>>>>>> Hi Joseph,
>>>>>>
>>>>>> thanks for the feedback, but I'm afraid that I can't reproduce any of
>>>>>> these issues on my side. :(
>>>>>>
>>>>>> - Default zoom levels on Windows (10) are *exactly* the same as on
>>>>>> Linux and Mac for me. Note that otherwise all the help patches would be
>>>>>> completely out of whack, and they look fine to me. Well, there are some
>>>>>> minor imperfections due to old Windows code special-casing for nw.js
>>>>>> 0.14.7, but I think that Ico already has a fix ready for that which will be
>>>>>> in the next release. If that is not what you see, then maybe (this is just
>>>>>> a wild guess) it's a specific patch and you have zoom save/restore enabled
>>>>>> in the GUI prefs? If it's not one of those things, please post a screenshot
>>>>>> of a minimal sample (preferably one of the help patches shipping with Purr)
>>>>>> which seems out of whack to you.
>>>>>>
>>>>>> - We've already discussed your issues with Purr occasionally freezing
>>>>>> off-list, but as I said, I can't reproduce this on any of my Linux boxes
>>>>>> either. So if anyone seems to have similar issues, please report them so
>>>>>> that we can begin tracking down the issue. Joseph, I understand that this
>>>>>> is frustrating, but the hard reality is that we can't fix bugs that we
>>>>>> can't reproduce. :( As soon as we can reproduce them, we can probably
>>>>>> identify the issue and fix it. But until then we'll have to wait and see
>>>>>> whether someone can confirm your problems and tell us exactly how to
>>>>>> reproduce these issues, or at least come up with a good explanation.
>>>>>>
>>>>>> Best,
>>>>>> Albert
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Fri, Oct 2, 2020 at 11:31 PM Linux ROUEN Normandie <
>>>>>> linux.rouen at free.fr> wrote:
>>>>>>
>>>>>>> Hello All,
>>>>>>>
>>>>>>> Purr Data 2.15.0 is a real great release. Thanks and congratulations
>>>>>>> to all contributors. :-)
>>>>>>>
>>>>>>> It was successfully installed/updated under Windows 10 v2004
>>>>>>> (32-bit) and Linux Mint 20 Cinnamon, Ubuntu Studio 20.04 Xfce and Manjaro
>>>>>>> 20.1 KDE Plasma and it's working well, except few annoying bugs.
>>>>>>>
>>>>>>> @Ico, [number2] objects are looking as good as under 2.14.2 last
>>>>>>> preview.
>>>>>>>
>>>>>>> PB-1: The graphics rendering is not the same on Windows vs all
>>>>>>> GNU/Linux.
>>>>>>> Under Windows when opening a project saved under Linux:
>>>>>>> - the zoom level of the main patch is ~ -1 smaller,
>>>>>>> - the zoom level of all sub-patches is ~ +1 bigger (and not ~ -1),
>>>>>>> and
>>>>>>> - the main window size of he project seems a little bit bigger.
>>>>>>> NW.js has been updated to the same 0.24.4 version than the Linux's
>>>>>>> one. Is it the issue?
>>>>>>>
>>>>>>> PB-2: Under Linux (where I'm mainly working), 2.15.0 has not fixed
>>>>>>> yet the *random freezes* (main patch or sub-patches) from few seconds up to
>>>>>>> complete freeze of the application awa the whole PC (except the visible
>>>>>>> mouse cursor but its click is with no effect) just when you are doing
>>>>>>> (simple) *edition tasks* (with neither MIDI nor Audio activity and
>>>>>>> DSP=OFF). This is true since a little bit more than one year when I have
>>>>>>> started using Purr Data (at that time 2.9.0).
>>>>>>>
>>>>>>> - - - - - - - - - - - - - - - - - - - -
>>>>>>> Best, Joseph Gastelais
>>>>>>> - - - - - - - - - - - - - - - - - - - -
>>>>>>>
>>>>>>> Le 01/10/2020 à 00:17, Albert Graef a écrit :
>>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> It’s time for another release with the latest bugfixes and some
>>>>>>> interesting new features. Download it here (Mac/Windows):
>>>>>>> https://github.com/agraef/purr-data/releases/tag/2.15.0
>>>>>>>
>>>>>>> As usual, Linux packages are available from the OBS
>>>>>>> <https://agraef.github.io/purr-data/#jgu-packages>. *Download
>>>>>>> <https://software.opensuse.org/download/package?package=purr-data&project=home%3Aaggraef>*
>>>>>>> Bugfixes
>>>>>>>
>>>>>>>    - Fixed Alt-Click popup issues reported by Joseph Gastelais (AG)
>>>>>>>    - Cosmetic fixes to declare error reporting (AG)
>>>>>>>    - Disable passing of key presses globally when an object grabs
>>>>>>>    focus via glist_grab (Ico)
>>>>>>>    - Fixed asynchronous getscroll and activate regression (Ico)
>>>>>>>    - Fixed openpanel unable to open a custom path on Windows (Ico)
>>>>>>>    - Disabled excessive coll legacy call warnings (Ico)
>>>>>>>
>>>>>>> New features
>>>>>>>
>>>>>>>    - Improvements to iemgui numbox (drawstyle, font sizing and
>>>>>>>    dialog) (Ico)
>>>>>>>    *Note:* The new numbox drawing style will change the numbox size
>>>>>>>    on existing patches.
>>>>>>>    - Private abstractions (Guillem, GSoC 2020)
>>>>>>>    Please check the [ab] help patch and the corresponding section
>>>>>>>    in the “Cat” tutorial
>>>>>>>    <https://agraef.github.io/purr-data-intro/Purr-Data-Intro.html#subpatch-and-abstraction-features>
>>>>>>>    !
>>>>>>>
>>>>>>> Enjoy! :)
>>>>>>> Albert
>>>>>>> --
>>>>>>> Dr. Albert Gr"af
>>>>>>> Computer Music Research Group, JGU Mainz, Germany
>>>>>>> Email: aggraef at gmail.com, web: https://agraef.github.io/
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> L2Ork-dev mailing listL2Ork-dev at disis.music.vt.eduhttps://disis.music.vt.edu/listinfo/l2ork-dev
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> L2Ork-dev mailing list
>>>>>>> L2Ork-dev at disis.music.vt.edu
>>>>>>> https://disis.music.vt.edu/listinfo/l2ork-dev
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Dr. Albert Gr"af
>>>>>> Computer Music Research Group, JGU Mainz, Germany
>>>>>> Email: aggraef at gmail.com, web: https://agraef.github.io/
>>>>>>
>>>>>> _______________________________________________
>>>>>> L2Ork-dev mailing listL2Ork-dev at disis.music.vt.eduhttps://disis.music.vt.edu/listinfo/l2ork-dev
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> L2Ork-dev mailing list
>>>>>> L2Ork-dev at disis.music.vt.edu
>>>>>> https://disis.music.vt.edu/listinfo/l2ork-dev
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> L2Ork-dev mailing listL2Ork-dev at disis.music.vt.eduhttps://disis.music.vt.edu/listinfo/l2ork-dev
>>>>>
>>>>> _______________________________________________
>>>>> L2Ork-dev mailing list
>>>>> L2Ork-dev at disis.music.vt.edu
>>>>> https://disis.music.vt.edu/listinfo/l2ork-dev
>>>>
>>>>
>>>>
>>>> --
>>>> Dr. Albert Gr"af
>>>> Computer Music Research Group, JGU Mainz, Germany
>>>> Email: aggraef at gmail.com, web: https://agraef.github.io/
>>>> _______________________________________________
>>>> L2Ork-dev mailing list
>>>> L2Ork-dev at disis.music.vt.edu
>>>> https://disis.music.vt.edu/listinfo/l2ork-dev
>>>
>>>
>>> _______________________________________________
>>> L2Ork-dev mailing listL2Ork-dev at disis.music.vt.eduhttps://disis.music.vt.edu/listinfo/l2ork-dev
>>>
>>>
>>> _______________________________________________
>>> L2Ork-dev mailing list
>>> L2Ork-dev at disis.music.vt.edu
>>> https://disis.music.vt.edu/listinfo/l2ork-dev
>>
>>
>> _______________________________________________
>> L2Ork-dev mailing listL2Ork-dev at disis.music.vt.eduhttps://disis.music.vt.edu/listinfo/l2ork-dev
>>
>>
>> _______________________________________________
>> L2Ork-dev mailing list
>> L2Ork-dev at disis.music.vt.edu
>> https://disis.music.vt.edu/listinfo/l2ork-dev
>
>
>
> --
> Dr. Albert Gr"af
> Computer Music Research Group, JGU Mainz, Germany
> Email: aggraef at gmail.com, web: https://agraef.github.io/
>
> _______________________________________________
> L2Ork-dev mailing listL2Ork-dev at disis.music.vt.eduhttps://disis.music.vt.edu/listinfo/l2ork-dev
>
>
> _______________________________________________
> L2Ork-dev mailing list
> L2Ork-dev at disis.music.vt.edu
> https://disis.music.vt.edu/listinfo/l2ork-dev



-- 
Dr. Albert Gr"af
Computer Music Research Group, JGU Mainz, Germany
Email: aggraef at gmail.com, web: https://agraef.github.io/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20201011/cd816551/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 69398 bytes
Desc: not available
URL: <http://disis.music.vt.edu/pipermail/l2ork-dev/attachments/20201011/cd816551/attachment-0001.png>


More information about the L2Ork-dev mailing list