good times
10 views
Skip to first unread message
Hairi Vogel (airi)
Apr 24, 2023, 2:15:55 AM4/24/23
to PraxisLIVE discussion group
Dear Neil.
I ' ve been working a lot with PraxisLive and it is marvellous.
It took quite some paradigm shifting in my mind, to work with this architecture. It feels more like analog electronics than digital-data-processing. GOOD:
I did a lot of coding that actually works very well. A way to keep states of components and recall them via animations, and some 30+ components (video processing, shaders, control modules) that conform to this.
I would like to contribute this work to the PraxisLive community, but I do not know how. It works well but the code is not all cleaned-up yet.
There are some flaws and questions, mostly minor, and I list them for you:
- Property which is declared as @Type.Integer responds to .type().toString()
with "Number", why that ?
Q: is there a way to get the min, max, def values used in declaring, back from the Property ?
- the layout of a graph is not consistent through saving/loading. Components move.
- the Property show all feature is not consistent through interface stops. It used to be in the previous version of PL.
- the GUI feature performs some odd auto-formatting and does not respond to edits in the cell parameters of items. No way.
During intensive live-programming I managed to crash PL in different ways. It never crashed during normal use (without hacking code or shaders live).
- When working on shaders it happens that the shader freezes. Stopping and restarting the hub solves this every time.
- stopping all hubs does noit free the memory on my GPU. It stays used and starting again just adds the memory needed to the part already used before. So sooner or later the interface becomes slow, because the GPU memory is full. Cleaning the project resolves this issue, frees the GPU memory. My patch is rather large and it takes minutes to build it, so this is a drag.
- I only discovered the GPU-memory hog now, so I am not sure if it is the reason for other crashes:
- sometimes all output windows close. the relative hubs stay on and cannot be stopped if not by cleaning/building. Once only even the IDE froze.
in a P3D component when using a switch statement, it defaults to throwing an AssertionError. That crashes the patch for sure.
I collected some crash dumps and put them in a file I attach.
I am happy to help, if I can, solve these things.
I wilol prepare a small patch that demonstrates the programming/morphing feature, so you can have a look at it and probably a laugh. There are better ways to implement that I am sure....
I am using Ryzen9, Radeon GTX6050, 64GB RAM, Win 11
All the best from Zürich, Switzerland. Keep rocking.
Hairi Vogel
I ' ve been working a lot with PraxisLive and it is marvellous.
It took quite some paradigm shifting in my mind, to work with this architecture. It feels more like analog electronics than digital-data-processing. GOOD:
I did a lot of coding that actually works very well. A way to keep states of components and recall them via animations, and some 30+ components (video processing, shaders, control modules) that conform to this.
I would like to contribute this work to the PraxisLive community, but I do not know how. It works well but the code is not all cleaned-up yet.
There are some flaws and questions, mostly minor, and I list them for you:
- Property which is declared as @Type.Integer responds to .type().toString()
with "Number", why that ?
Q: is there a way to get the min, max, def values used in declaring, back from the Property ?
- the layout of a graph is not consistent through saving/loading. Components move.
- the Property show all feature is not consistent through interface stops. It used to be in the previous version of PL.
- the GUI feature performs some odd auto-formatting and does not respond to edits in the cell parameters of items. No way.
During intensive live-programming I managed to crash PL in different ways. It never crashed during normal use (without hacking code or shaders live).
- When working on shaders it happens that the shader freezes. Stopping and restarting the hub solves this every time.
- stopping all hubs does noit free the memory on my GPU. It stays used and starting again just adds the memory needed to the part already used before. So sooner or later the interface becomes slow, because the GPU memory is full. Cleaning the project resolves this issue, frees the GPU memory. My patch is rather large and it takes minutes to build it, so this is a drag.
- I only discovered the GPU-memory hog now, so I am not sure if it is the reason for other crashes:
- sometimes all output windows close. the relative hubs stay on and cannot be stopped if not by cleaning/building. Once only even the IDE froze.
in a P3D component when using a switch statement, it defaults to throwing an AssertionError. That crashes the patch for sure.
I collected some crash dumps and put them in a file I attach.
I am happy to help, if I can, solve these things.
I wilol prepare a small patch that demonstrates the programming/morphing feature, so you can have a look at it and probably a laugh. There are better ways to implement that I am sure....
I am using Ryzen9, Radeon GTX6050, 64GB RAM, Win 11
All the best from Zürich, Switzerland. Keep rocking.
Hairi Vogel
Neil C Smith
Apr 25, 2023, 4:35:28 AM4/25/23
to praxi...@googlegroups.com
Hi,
On Mon, 24 Apr 2023 at 07:15, Hairi Vogel (airi) <hairi...@gmail.com> wrote:
> I ' ve been working a lot with PraxisLive and it is marvellous.
> It took quite some paradigm shifting in my mind, to work with this architecture. It feels more like analog electronics than digital-data-processing. GOOD:
Glad you're liking it! :-) And glad the paradigm shift works for you.
It was certainly initially inspired by working with patching
environments that mimicked analog electronics, but wanting to be able
to re-code their components.
> I did a lot of coding that actually works very well. A way to keep states of components and recall them via animations, and some 30+ components (video processing, shaders, control modules) that conform to this.
> I would like to contribute this work to the PraxisLive community, but I do not know how. It works well but the code is not all cleaned-up yet.
Depending on whether they're most useful as reusable components or as
examples of ways to do things, then contributions are welcome to
https://github.com/praxis-live/templates
https://github.com/praxis-live/components
Releases of these repositories are what get downloaded from the start
page and added to the projects and components menus.
They haven't been updated in a little while, unfortunately. NetBeans
is taking up the majority of my time at the moment (which will benefit
PraxisLIVE too), and the time I have is concentrated towards v6.
> There are some flaws and questions, mostly minor, and I list them for you:
>
> - Property which is declared as @Type.Integer responds to .type().toString()
> with "Number", why that ?
Because the underlying type system used in messaging only has Number.
There were a variety of reasons for doing this. Properties expose a
flag that they will convert the input to an integer - similar to mix,
max, etc. ... which of course leads to the same issues as ...
> Q: is there a way to get the min, max, def values used in declaring, back from the Property ?
Short answer, at the moment, no. As with most things in PraxisLIVE,
there's a complicated way around this! :-)
What's your use case? There may be other ways to do it.
> - the layout of a graph is not consistent through saving/loading. Components move.
That's concerning. I haven't noticed this myself. Some code in the
loading UI changed in the last release to give visual feedback on
loading - I wonder if this is causing an issue for you.
> - the Property show all feature is not consistent through interface stops. It used to be in the previous version of PL.
Yes, it looks like the above change might have broken this. Will look into it.
> - the GUI feature performs some odd auto-formatting and does not respond to edits in the cell parameters of items. No way.
The GUI feature has not had any work for a while! I might look to do
something else in v6. It uses MigLayout underneath which does
occasionally do some interesting things!
You should be able to move the cells of UI items by using the arrows
in the toolbar, or the arrow keys. I never did get around to drag and
drop.
> During intensive live-programming I managed to crash PL in different ways. It never crashed during normal use (without hacking code or shaders live).
Well, hacking code and shaders is normal use! :-)
> - When working on shaders it happens that the shader freezes. Stopping and restarting the hub solves this every time.
This can be an issue, and can be a bit GPU driver reliant.
> - stopping all hubs does noit free the memory on my GPU. It stays used and starting again just adds the memory needed to the part already used before. So sooner or later the interface becomes slow, because the GPU memory is full. Cleaning the project resolves this issue, frees the GPU memory. My patch is rather large and it takes minutes to build it, so this is a drag.
>
> - I only discovered the GPU-memory hog now, so I am not sure if it is the reason for other crashes:
> - sometimes all output windows close. the relative hubs stay on and cannot be stopped if not by cleaning/building. Once only even the IDE froze.
Hub? Roots / patches? All output windows?
I'm not sure if we're using the same terminology exactly.
Do you have more than one video patch / window in the same project?
That can definitely cause issues if not handled carefully due to the
design of Processing.
> in a P3D component when using a switch statement, it defaults to throwing an AssertionError. That crashes the patch for sure.
In Java code? I can't replicate this. Can you share a bit more?
> I collected some crash dumps and put them in a file I attach.
Well, it seems to be crashing in the GPU driver. At the moment, not
sure more than that.
> All the best from Zürich, Switzerland. Keep rocking.
Thanks, and all the best from Oxford, UK. :-)
Neil
On Mon, 24 Apr 2023 at 07:15, Hairi Vogel (airi) <hairi...@gmail.com> wrote:
> I ' ve been working a lot with PraxisLive and it is marvellous.
> It took quite some paradigm shifting in my mind, to work with this architecture. It feels more like analog electronics than digital-data-processing. GOOD:
It was certainly initially inspired by working with patching
environments that mimicked analog electronics, but wanting to be able
to re-code their components.
> I did a lot of coding that actually works very well. A way to keep states of components and recall them via animations, and some 30+ components (video processing, shaders, control modules) that conform to this.
> I would like to contribute this work to the PraxisLive community, but I do not know how. It works well but the code is not all cleaned-up yet.
examples of ways to do things, then contributions are welcome to
https://github.com/praxis-live/templates
https://github.com/praxis-live/components
Releases of these repositories are what get downloaded from the start
page and added to the projects and components menus.
They haven't been updated in a little while, unfortunately. NetBeans
is taking up the majority of my time at the moment (which will benefit
PraxisLIVE too), and the time I have is concentrated towards v6.
> There are some flaws and questions, mostly minor, and I list them for you:
>
> - Property which is declared as @Type.Integer responds to .type().toString()
> with "Number", why that ?
There were a variety of reasons for doing this. Properties expose a
flag that they will convert the input to an integer - similar to mix,
max, etc. ... which of course leads to the same issues as ...
> Q: is there a way to get the min, max, def values used in declaring, back from the Property ?
there's a complicated way around this! :-)
What's your use case? There may be other ways to do it.
> - the layout of a graph is not consistent through saving/loading. Components move.
loading UI changed in the last release to give visual feedback on
loading - I wonder if this is causing an issue for you.
> - the Property show all feature is not consistent through interface stops. It used to be in the previous version of PL.
> - the GUI feature performs some odd auto-formatting and does not respond to edits in the cell parameters of items. No way.
something else in v6. It uses MigLayout underneath which does
occasionally do some interesting things!
You should be able to move the cells of UI items by using the arrows
in the toolbar, or the arrow keys. I never did get around to drag and
drop.
> During intensive live-programming I managed to crash PL in different ways. It never crashed during normal use (without hacking code or shaders live).
> - When working on shaders it happens that the shader freezes. Stopping and restarting the hub solves this every time.
> - stopping all hubs does noit free the memory on my GPU. It stays used and starting again just adds the memory needed to the part already used before. So sooner or later the interface becomes slow, because the GPU memory is full. Cleaning the project resolves this issue, frees the GPU memory. My patch is rather large and it takes minutes to build it, so this is a drag.
>
> - I only discovered the GPU-memory hog now, so I am not sure if it is the reason for other crashes:
> - sometimes all output windows close. the relative hubs stay on and cannot be stopped if not by cleaning/building. Once only even the IDE froze.
I'm not sure if we're using the same terminology exactly.
Do you have more than one video patch / window in the same project?
That can definitely cause issues if not handled carefully due to the
design of Processing.
> in a P3D component when using a switch statement, it defaults to throwing an AssertionError. That crashes the patch for sure.
> I collected some crash dumps and put them in a file I attach.
sure more than that.
> All the best from Zürich, Switzerland. Keep rocking.
Neil
Hans Heinrich Vogel
Apr 25, 2023, 5:45:27 AM4/25/23
to praxi...@googlegroups.com
On 25 Apr 2023, at 10:35, Neil C Smith <ne...@neilcsmith.net> wrote:
- I only discovered the GPU-memory hog now, so I am not sure if it is the reason for other crashes:
- sometimes all output windows close. the relative hubs stay on and cannot be stopped if not by cleaning/building. Once only even the IDE froze.
Hub? Roots / patches? All output windows?
I mean hub refering to the green dots in the HUB panel, where patches can be turned on/off.
all output windows close (i use 2 or 3 video patches one window each)
I'm not sure if we're using the same terminology exactly.
mine is:
a patch is a page in the IDE that shows components and connections graphically. (there are also invisible connections)
a root I do not know what ist is if not a name for the patch
a hub is represented by a grey/green dot and is a machine in a sandbox that runs the code stored in a patch.
each patch has 1 hub.
the patches cannot share data if not by connections (messaging)
Do you have more than one video patch / window in the same project?
That can definitely cause issues if not handled carefully due to the
design of Processing.
aha… yes i am using 2 or 3 video patches each 1 window simultaneously, all in the same project.
it seemed to me that that is the only way to use more than 1 screen.
I have now 2 screens in use. 1 for the video output and one for the touchscreen that shows the programming controls.
patches can get big and it is easier to use more than one (where poss) than using containers.
the main regret about containers is that one can export a port to the container, but not the whole interface to the property.
example. to cklick on a trigger in the container one always has to open it. same for looking at values..
so:
what is the best way to work with multiple output windows ? (if there is one...)
thanx
h
Neil C Smith
Apr 25, 2023, 6:18:26 AM4/25/23
to praxi...@googlegroups.com
On Tue, 25 Apr 2023 at 10:45, Hans Heinrich Vogel <hairi...@gmail.com> wrote:
> all output windows close (i use 2 or 3 video patches one window each)
...
> all output windows close (i use 2 or 3 video patches one window each)
> I'm not sure if we're using the same terminology exactly.
>
> mine is:
> a patch is a page in the IDE that shows components and connections graphically. (there are also invisible connections)
> a root I do not know what ist is if not a name for the patch
Root and patch are sort of the same thing. I used the term "patch" in
>
> mine is:
> a patch is a page in the IDE that shows components and connections graphically. (there are also invisible connections)
> a root I do not know what ist is if not a name for the patch
the UI for a root that is edited as a graph (audio, data, video). The
GUI, OSC and MIDI roots, for example, are not called patch.
> a hub is represented by a grey/green dot and is a machine in a sandbox that runs the code stored in a patch.
toggle the system button. Each individual dot is a root / patch.
Effectively you have one hub per project (in earlier versions of
PraxisLIVE all projects ran together in one hub).
There is a bit more on this terminology at
https://docs.praxislive.org/architecture/
> the patches cannot share data if not by connections (messaging)
another within the same hub / project. Clicking the ... button on the
"address" property will open a component browser across all patches so
you can select a control.
If you look at the code for that, you can see use of the tell(..)
function to do this, which you can add into your own code.
There is also the recently added ask(..) function - see the notes from
v5.5. https://github.com/praxis-live/praxis-live/releases/tag/v5.5.0
It's a little clunky to use at the moment, as it's the first part of
the plan!
And, if you click the cog icon in the component browser you'll notice
that .code appears as one of the controls on any component. You can
send code as Strings to rewrite other components.
> aha… yes i am using 2 or 3 video patches each 1 window simultaneously, all in the same project.
the hub configuration to run each video patch in a separate process.
See https://docs.praxislive.org/projects/#hub-configuration
You want to repeat the video section in there for each output you
need. Make sure each entry has a unique name, possibly the name of
the patch, and that the id-pattern for each entry matches the id of
the patch.
Hopefully that makes sense? You must edit this before you run the project.
> patches can get big and it is easier to use more than one (where poss) than using containers.
> the main regret about containers is that one can export a port to the container, but not the whole interface to the property.
> example. to cklick on a trigger in the container one always has to open it. same for looking at values..
have to re-code the container. At some point we might bring back the
UI aspect, but it will generate the required container code.
You can always add a trigger on the container that routes through to
the child components - an input port variant is mentioned in the
release notes for v5.4.0
https://github.com/praxis-live/praxis-live/releases/tag/v5.4.0
Some of these recent features need better docs! Checking the release
notes is also worth doing.
Best wishes,
Neil
Hairi Vogel
Apr 25, 2023, 9:55:00 AM4/25/23
to praxi...@googlegroups.com
Il giorno mar 25 apr 2023 alle ore 12:18 Neil C Smith
<ne...@neilcsmith.net> ha scritto:
I got that all that, i am sending lots of messages via tell to lots of
components, sometimes all there are (30+) and they respond with long
strings. It is amazing , Never lost a message.
> And, if you click the cog icon in the component browser you'll notice
> that .code appears as one of the controls on any component. You can
> send code as Strings to rewrite other components.
??? components browser , cog icon where is all that ??
>
> > aha… yes i am using 2 or 3 video patches each 1 window simultaneously, all in the same project.
>
> To use multiple video patches in the same project, you need to edit
> the hub configuration to run each video patch in a separate process.
>
> See https://docs.praxislive.org/projects/#hub-configuration
>
> You want to repeat the video section in there for each output you
> need. Make sure each entry has a unique name, possibly the name of
> the patch, and that the id-pattern for each entry matches the id of
> the patch.
>
> Hopefully that makes sense? You must edit this before you run the project.
this made sense and i am running now two processes named after the
relative patches. I see that in the Win 11 system tool.
let's see if there are any more crashes, probably not. For your info:
I used 3 windows in 1 process for hours without trouble.
> > patches can get big and it is easier to use more than one (where poss) than using containers.
> > the main regret about containers is that one can export a port to the container, but not the whole interface to the property.
> > example. to cklick on a trigger in the container one always has to open it. same for looking at values..
>
> True. Old style containers in PraxisLIVE used to have this. Now you
> have to re-code the container. At some point we might bring back the
> UI aspect, but it will generate the required container code.
>
> You can always add a trigger on the container that routes through to
> the child components - an input port variant is mentioned in the
> release notes for v5.4.0
> https://github.com/praxis-live/praxis-live/releases/tag/v5.4.0
i missed that, glory. that solves a lot of trouble !!
Still, i updated drivers and Win 11 and my current patch weighs ca 3GB
on the dedicated memory of my Radeon RX6650XT (that is the precise
number) but this memory is not freed when i stop the patch. It remains
and restarting the patch just adds another 3GB to the load. 8GB is
enough for 1 restart, then it gets slooow. The reason I guess it could
have something to do with PL is that if I clean the project, the load
disappears. So there is something happening when the IDE closes (a
general reset to the card ??) tha would be needed when the patch
stops. If it is a system/card issue for me it's worse ;-(
cheers
h
PS: I have understood that PL is not meant specifically for being
played like an instrument. But that is exactly what I was looking for
for ages and it was possible to implement such a thing now. I will
make you a demo. I have some expertise in the field of interactive
audio/video installations and to my knowledge there's no such thing
around. I added a concept to the Properties I call Behaviour. It
allows do determine how values change, a widely extended Easing
feature that shall deal with any value. I haven't got the time to
figure out what string-morphing (i mean the content) shall be able to
do. I make extended use of the animation feature, another of your
masterpieces. Along with the concepts of Value and Property. Data
types are shifting from being a memory and speed issue to become
artistic qualities. They now are what you make out of it. That is a
paradigm-shift as big as OOP was. It has similarity with SuperCollider
where no typecasting takes place at all and you teach the data items
what to do. Hope this makes sense :-)
chapeau
h
<ne...@neilcsmith.net> ha scritto:
components, sometimes all there are (30+) and they respond with long
strings. It is amazing , Never lost a message.
> And, if you click the cog icon in the component browser you'll notice
> that .code appears as one of the controls on any component. You can
> send code as Strings to rewrite other components.
>
> > aha… yes i am using 2 or 3 video patches each 1 window simultaneously, all in the same project.
>
> To use multiple video patches in the same project, you need to edit
> the hub configuration to run each video patch in a separate process.
>
> See https://docs.praxislive.org/projects/#hub-configuration
>
> You want to repeat the video section in there for each output you
> need. Make sure each entry has a unique name, possibly the name of
> the patch, and that the id-pattern for each entry matches the id of
> the patch.
>
> Hopefully that makes sense? You must edit this before you run the project.
relative patches. I see that in the Win 11 system tool.
let's see if there are any more crashes, probably not. For your info:
I used 3 windows in 1 process for hours without trouble.
> > patches can get big and it is easier to use more than one (where poss) than using containers.
> > the main regret about containers is that one can export a port to the container, but not the whole interface to the property.
> > example. to cklick on a trigger in the container one always has to open it. same for looking at values..
>
> True. Old style containers in PraxisLIVE used to have this. Now you
> have to re-code the container. At some point we might bring back the
> UI aspect, but it will generate the required container code.
>
> You can always add a trigger on the container that routes through to
> the child components - an input port variant is mentioned in the
> release notes for v5.4.0
> https://github.com/praxis-live/praxis-live/releases/tag/v5.4.0
Still, i updated drivers and Win 11 and my current patch weighs ca 3GB
on the dedicated memory of my Radeon RX6650XT (that is the precise
number) but this memory is not freed when i stop the patch. It remains
and restarting the patch just adds another 3GB to the load. 8GB is
enough for 1 restart, then it gets slooow. The reason I guess it could
have something to do with PL is that if I clean the project, the load
disappears. So there is something happening when the IDE closes (a
general reset to the card ??) tha would be needed when the patch
stops. If it is a system/card issue for me it's worse ;-(
cheers
h
PS: I have understood that PL is not meant specifically for being
played like an instrument. But that is exactly what I was looking for
for ages and it was possible to implement such a thing now. I will
make you a demo. I have some expertise in the field of interactive
audio/video installations and to my knowledge there's no such thing
around. I added a concept to the Properties I call Behaviour. It
allows do determine how values change, a widely extended Easing
feature that shall deal with any value. I haven't got the time to
figure out what string-morphing (i mean the content) shall be able to
do. I make extended use of the animation feature, another of your
masterpieces. Along with the concepts of Value and Property. Data
types are shifting from being a memory and speed issue to become
artistic qualities. They now are what you make out of it. That is a
paradigm-shift as big as OOP was. It has similarity with SuperCollider
where no typecasting takes place at all and you teach the data items
what to do. Hope this makes sense :-)
chapeau
h
Hairi Vogel
Apr 25, 2023, 10:32:18 AM4/25/23
to praxi...@googlegroups.com
found the cog and the components browser , will try to send code to a
component: -00000
component: -00000
Neil C Smith
Apr 25, 2023, 10:33:09 AM4/25/23
to praxi...@googlegroups.com
On Tue, 25 Apr 2023 at 14:55, Hairi Vogel <hairi...@gmail.com> wrote:
> I got that all that, i am sending lots of messages via tell to lots of
> components, sometimes all there are (30+) and they respond with long
> strings. It is amazing , Never lost a message.
Good to know!
> I got that all that, i am sending lots of messages via tell to lots of
> components, sometimes all there are (30+) and they respond with long
> strings. It is amazing , Never lost a message.
> ??? components browser , cog icon where is all that ??
button to the right-hand side of the property in the property editor.
That should open a dialog where you can search through all components
and their controls. The toggle button at the top right of that dialog
will cause extra controls to show up, including .code
Or you can just set the tell address to /component/address.code of course! :-)
> this made sense and i am running now two processes named after the
> relative patches. I see that in the Win 11 system tool.
> let's see if there are any more crashes, probably not. For your info:
> I used 3 windows in 1 process for hours without trouble.
work fine for ages, and sometimes it'll work fine on some graphics
cards. Often you're fine until you delete something.
> Still, i updated drivers and Win 11 and my current patch weighs ca 3GB
> on the dedicated memory of my Radeon RX6650XT (that is the precise
> number) but this memory is not freed when i stop the patch. It remains
> and restarting the patch just adds another 3GB to the load. 8GB is
> enough for 1 restart, then it gets slooow. The reason I guess it could
> have something to do with PL is that if I clean the project, the load
> disappears.
sub-process(es) that the video is running in.
Somehow you have a reference to the old Processing window hanging
around. I'll do some checking to see if I can reproduce a hanging
reference in any of my test code, but it could be something you're
holding on to in your code too.
> PS: I have understood that PL is not meant specifically for being
> audio/video installations and to my knowledge there's no such thing
> around.
Well, that's my original background too, and why I started it in the
> around.
first place. Although it's certainly evolving in different and more
generic directions, I hope it still serves that purpose.
It was used to create -
https://www.neilcsmith.net/projects/installation/meeting-point/
https://www.neilcsmith.net/projects/installation/justitia/
https://www.neilcsmith.net/projects/installation/cabinet-of-luminosities/
and loosely based on the software I wrote for
https://www.neilcsmith.net/projects/installation/sound-pool/
> Along with the concepts of Value and Property. Data
> types are shifting from being a memory and speed issue to become
> artistic qualities. They now are what you make out of it. That is a
> paradigm-shift as big as OOP was. It has similarity with SuperCollider
> where no typecasting takes place at all and you teach the data items
> what to do. Hope this makes sense :-)
of this https://wiki.c2.com/?AlanKayOnMessaging - PraxisLIVE is very
much influenced by *actual* OOP. :-)
Best wishes,
Neil
Neil C Smith
Apr 25, 2023, 11:17:06 AM4/25/23
to praxi...@googlegroups.com
On Tue, 25 Apr 2023 at 15:32, Neil C Smith <ne...@neilcsmith.net> wrote:
> Somehow you have a reference to the old Processing window hanging
> around. I'll do some checking to see if I can reproduce a hanging
> reference in any of my test code ...
> Somehow you have a reference to the old Processing window hanging
> around. I'll do some checking to see if I can reproduce a hanging
OK, I know where the problem is. I'll see if I can get it fixed and
in the next release.
In the meantime, see if you can get away with minimising the window
rather than stopping the patch.
Best wishes,
Neil
Hans Heinrich Vogel
Apr 26, 2023, 11:55:36 AM4/26/23
to praxi...@googlegroups.com
that´s good. I can live with it. Closing the window is a reminiscence to non-Live coding, anyway.
thjere´s hardly need for it now.
best
h
> --
> You received this message because you are subscribed to a topic in the Google Groups "PraxisLIVE discussion group" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/praxis-live/BcX7hY3RF4w/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to praxis-live...@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/praxis-live/CAMYaZEsEkS8R3MPxoeuLLMAEHfVHrtOpsW-Yvft8pB4Pwb%3DDPQ%40mail.gmail.com.
thjere´s hardly need for it now.
best
h
> You received this message because you are subscribed to a topic in the Google Groups "PraxisLIVE discussion group" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/praxis-live/BcX7hY3RF4w/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to praxis-live...@googlegroups.com.
> To view this discussion on the web, visit https://groups.google.com/d/msgid/praxis-live/CAMYaZEsEkS8R3MPxoeuLLMAEHfVHrtOpsW-Yvft8pB4Pwb%3DDPQ%40mail.gmail.com.
Neil C Smith
May 16, 2023, 11:37:27 AM5/16/23
to praxi...@googlegroups.com
On Wed, 26 Apr 2023 at 16:55, Hans Heinrich Vogel <hairi...@gmail.com> wrote:
>
> that´s good. I can live with it. Closing the window is a reminiscence to non-Live coding, anyway.
> thjere´s hardly need for it now.
Just to say, I've tracked down and hopefully fixed the memory leak
>
> that´s good. I can live with it. Closing the window is a reminiscence to non-Live coding, anyway.
> thjere´s hardly need for it now.
issue in the LWJGL renderer when closing / re-opening windows.
Need to do some more testing on a few things, but 5.6 should be
released in a week or so. It's all in the two source repos as of
today.
I've also fixed the issue with the view-all properties attribute not
being set correctly at build time. And I've hopefully made a change
that will speed up build times for large projects (due to being held
up in the UI side when building).
Best wishes,
Neil
Hans Heinrich Vogel
May 17, 2023, 3:27:06 AM5/17/23
to praxi...@googlegroups.com
Hi Neil.
This is of course good news, given the fact that PL can handle very large projects,
like 30+ shaders all in full-res. If you want me to run a beta-5.6 on my setup, just send me a link.
I tried, without really knowing what I was doing, to send text to the cog-code input of a component.
As far as I understand the whole code is replaced. Is there some documentation regarding this (amazing) feature ?
How do I access the code running inside the component ? It would be - maybe - convenient to be able to add stuff to an existing component.
Have a nice day
H
--
You received this message because you are subscribed to the Google Groups "PraxisLIVE discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to praxis-live...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/praxis-live/CAMYaZEtL12q5mwP-wH9-p09Qz1yijaqzT6%2BGRpfOz1ueTo-pEQ%40mail.gmail.com.
Hans Heinrich Vogel
May 17, 2023, 3:30:17 AM5/17/23
to praxi...@googlegroups.com
just getting to this stuff. will give you feedback later.
cheers
h
Neil C Smith
May 17, 2023, 5:51:34 AM5/17/23
to Praxis LIVE software discussion group
Hi,
On Wed, 17 May 2023, 08:27 Hans Heinrich Vogel, <hairi...@gmail.com> wrote:
I tried, without really knowing what I was doing, to send text to the cog-code input of a component.As far as I understand the whole code is replaced. Is there some documentation regarding this (amazing) feature ?How do I access the code running inside the component ? It would be - maybe - convenient to be able to add stuff to an existing component.
It's kind of documented! :-) Code is really just a text property like any other String. You can query the current value using ask(..) etc.
Of course, the under the hood details of how the String becomes the component code is a bit more detailed - if you're interested covered in https://www.praxislive.org/blog/just-in-time-programming/
I'll let you know on a beta. I'd like to set up GitHub workflows to produce a daily build at some point.
Best wishes,
Neil
Reply all
Reply to author
Forward
0 new messages