Re: [PD] PD Internal Message "filename"

[IOhannes m zmoelnig]

On 2015-09-24 05:24, Chris wrote:
> Hello list!
> 
> I've been working a lot with internal messages in the past few days to
> dynamically create patches. I noticed when switching from pd-extended to
> vanilla that sending "filename example.pd /path/to/file" to [s pd] gives me
> an error: "pd: unknown message filename example.pd /path/to/file". Is this
> feature not available in vanilla, or is there something else going on?

what is "this feature" supposed to do?

fgasdmr
IOhannes




signature.asc
Description: OpenPGP digital signature
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] more delay weirdness

[Christof Ressi]

> cause I'm expecting the object to behave as it should

 

more precisely, you're expecting the object to behave as YOU THINK it should ;-). But you're right that this discussion can go on forever. I just want to point out a last time that there's a difference between a bug and improper documentation. For example there's a technical reason why for computing audio in blocks, the reading onset for [vd~] would be less than the buffer size of [delwrite~] (especially when deliberately increasing the block size). This is totally logical and problems only arise because of vague terms like 'maximum delay time'. So it's not that the behaviour of [vd~] is wrong, but the helpfile - and that's an important difference!

 

Regarding the behaviour of overlapping subpatches you just have to accept how Pd works. Changing its behaviour will break hundreds of patches.

To repeat myself, I personally think most of what you declare as a 'bug' is just a matter of missing or misleading documentation.

 

Cheers

 
PS: I'm not claiming the last word on this subject

 

 

Gesendet: Donnerstag, 24. September 2015 um 18:54 Uhr
Von: "Alexandre Torres Porres" 
An: "Christof Ressi" 
Cc: Pd-List 
Betreff: Re: Re: [PD] more delay weirdness



2015-09-24 9:53 GMT-03:00 Christof Ressi :




If my last post felt like a repression, I deeply regret that!




 

no worries ;) just had to bring it up.



 








but you were calling other things a bug, that were no bugs in a technical sense (how ms are calculated in overlapping subpatches, how the maximum index for [vd~] is actual less than the buffer size, etc.).

(...) 

I'm personally rather careful with calling something a bug because chances are high that there's simply a technical reason I didn't consider or couldn't understand.








 

Yeah, I see the way you think but I think quite differently and I still consider these things a "bug". I know there might be technical issues that explain why things happen. But when nothing tells me that when using an overlapped block that I have to adjust time and frequency for objects, I see that as a bug, cause I'm expecting the object to behave as it should, and it just doesn't, and then my patches don't work and it sucks. I have to ask the list why the heck something is not happening and why do I need workarounds... someone had to look deeply in the code and sort it out...

Well, and instead of building workarounds in the patch, I know there's a way to "fix" this in the object (just divide by the overlap number automatically in the code, seems easier than explaining it somewhere in the help file of a block~) - it wouldn't be impossible to fix it.

 

Regarding the maximum delay time. Well, help file says it can go up to the total length and it doesn't... so... bug detected. I'm sure there's a reason why it's happening, but I don't think its impossible to fix it and make it happen as well.

 

but anyway, I get your view, but I'll just disagree :) not sure if we should discuss and try to change each other's minds.

 

cheers

 

 








___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] PD Internal Message "filename"

[Jonathan Wilkes via Pd-list]

At least in Pd-l2ork, clicking "New" in the "File" menu sends a series of 
messages to Pd to set the filename/dir,create a new canvas, and "pop" the new 
canvas.  So I'm guessing Chris has figured out he can send thesemessages in 
Pd-extended 0.42 to manually create a new patch with whatever name/directory he 
wants.
Same thing happens in Pd-Vanilla, except it's a single "menunew" message sent 
to Pd and the canvas gets named,created and pop'd as a result.
Pd-l2ork has [preset_node] and [preset_hub], but Pd-l2ork currently only runs 
on GNU/Linux.
-Jonathan

 


 On Thursday, September 24, 2015 10:24 AM, IOhannes m zmoelnig 
 wrote:
   

 On 2015-09-24 16:05, Chris wrote:
> Thanks Jonathan, menunew did the trick!
> 
> IOhannes: it creates and opens a new patch -- first argument is the
> filename, second argument is the path.

according to the source code it does not.
it simply sets the filename and path for the next to-be-created abstraction.


> It turns out this is very handy for
> dynamically creating abstractions, e.g. for state-saving/presets :)

hmm, why don't you just use a text-file (or multiples thereof) for presets?
dynamic patching can generally be avoided.

e.g. marian's [kollabs] is a very powerful Pd-vanilla state-saving
system, that doesn't rely on any undocumented features.


fgmsdr
IOhannes





[kollabs] https://github.com/m---w/kollabs

___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list


  ___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] more delay weirdness

[Alexandre Torres Porres]

2015-09-24 9:53 GMT-03:00 Christof Ressi :

> If my last post felt like a repression, I deeply regret that!
>

no worries ;) just had to bring it up.

but you were calling other things a bug, that were no bugs in a technical
> sense (how ms are calculated in overlapping subpatches, how the maximum
> index for [vd~] is actual less than the buffer size, etc.).
> (...)
> I'm personally rather careful with calling something a bug because chances
> are high that there's simply a technical reason I didn't consider or
> couldn't understand.
>

Yeah, I see the way you think but I think quite differently and I still
consider these things a "bug". I know there might be technical issues that
explain why things happen. But when nothing tells me that when using an
overlapped block that I have to adjust time and frequency for objects, I
see that as a bug, cause I'm expecting the object to behave as it should,
and it just doesn't, and then my patches don't work and it sucks. I have to
ask the list why the heck something is not happening and why do I need
workarounds... someone had to look deeply in the code and sort it out...

Well, and instead of building workarounds in the patch, I know there's a
way to "fix" this in the object (just divide by the overlap number
automatically in the code, seems easier than explaining it somewhere in the
help file of a block~) - it wouldn't be impossible to fix it.

Regarding the maximum delay time. Well, help file says it can go up to the
total length and it doesn't... so... bug detected. I'm sure there's a
reason why it's happening, but I don't think its impossible to fix it and
make it happen as well.

but anyway, I get your view, but I'll just disagree :) not sure if we
should discuss and try to change each other's minds.

cheers
___
Pd-list@lists.iem.at mailing list
UNSUBSCRIBE and account-management -> 
http://lists.puredata.info/listinfo/pd-list

Re: [PD] more delay weirdness

[William Huston]

First I think it is of critically importance for people to remain
extra-polite on big, international listservs.

I would suggest to make conscious effort to tone down any hostility,
frustration, or anger you are feeling before posting. Take a deep breath.

Recall, we are all doing this to (mostly) to have fun :)

Next, I think this discussion could have great pedagogical value to
intermediate PD patchers like me to explain what this is all about.

I'm sorry but I do not understand "overlapping sub-patches" or the issue
with [vd~].

I would wager there are others here in my boat.

I very much would appreciate some more discussion here. Diagrams would help
me very much.

Thanks!

PS: I am personally loving [vd~] at the moment. I just made an abstraction
called "AutoPhase3".
That and my "AutoPan3" makes a really awesome Leslie (rotating speaker)
simulation.

Basically, it takes a mono source and writes it into a circular buffer.

Then, I have 3x [vd~]'s reading, with an LFO on the delay time. I can
change the speed and depth of the LFO, as well as the phase-distance
between them.


It's so freaking awesome! I then take these 3 signals and send them to
discrete AutoPan modules. Again, speed and depth of LFO variable.

OMG, the fatness! Just take a simple saw oscillator, or even a sinusoid--
anything! And you can get lush flanger, phasor, and chorus effects.

I guess it's like FM so it can really warp the spectrum. Create artifacts
not found in the original.

You can get it on GitHub.
TinyURL.com / BHPDToolkit

FYI: There are several demo-patches with bugs in abstraction names.
Everything is there in the repository, but some abstraction names changed.
I will fix when I can.




On Thursday, September 24, 2015, Christof Ressi 
wrote:
>> cause I'm expecting the object to behave as it should
>
> more precisely, you're expecting the object to behave as YOU THINK it
should ;-). But you're right that this discussion can go on forever. I just
want to point out a last time that there's a difference between a bug and
improper documentation. For example there's a technical reason why for
computing audio in blocks, the reading onset for [vd~] would be less than
the buffer size of [delwrite~] (especially when deliberately increasing the
block size). This is totally logical and problems only arise because of
vague terms like 'maximum delay time'. So it's not that the behaviour of
[vd~] is wrong, but the helpfile - and that's an important difference!
>
> Regarding the behaviour of overlapping subpatches you just have to accept
how Pd works. Changing its behaviour will break hundreds of patches.
> To repeat myself, I personally think most of what you declare as a 'bug'
is just a matter of missing or misleading documentation.
>
> Cheers
>
> PS: I'm not claiming the last word on this subject
>
>
> Gesendet: Donnerstag, 24. September 2015 um 18:54 Uhr
> Von: "Alexandre Torres Porres" 
> An: "Christof Ressi" 
> Cc: Pd-List 
> Betreff: Re: Re: [PD] more delay weirdness
> 2015-09-24 9:53 GMT-03:00 Christof Ressi :
>>
>> If my last post felt like a repression, I deeply regret that!
>
>
> no worries ;) just had to bring it up.
>
>>
>> but you were calling other things a bug, that were no bugs in a
technical sense (how ms are calculated in overlapping subpatches, how the
maximum index for [vd~] is actual less than the buffer size, etc.).
>> (...)
>> I'm personally rather careful with calling something a bug because
chances are high that there's simply a technical reason I didn't consider
or couldn't understand.
>
>
> Yeah, I see the way you think but I think quite differently and I still
consider these things a "bug". I know there might be technical issues that
explain why things happen. But when nothing tells me that when using an
overlapped block that I have to adjust time and frequency for objects, I
see that as a bug, cause I'm expecting the object to behave as it should,
and it just doesn't, and then my patches don't work and it sucks. I have to
ask the list why the heck something is not happening and why do I need
workarounds... someone had to look deeply in the code and sort it out...
>
> Well, and instead of building workarounds in the patch, I know there's a
way to "fix" this in the object (just divide by the overlap number
automatically in the code, seems easier than explaining it somewhere in the
help file of a block~) - it wouldn't be impossible to fix it.
>
> Regarding the maximum delay time. Well, help file says it can go up to
the total length and it doesn't... so... bug detected. I'm sure there's a
reason why it's happening, but I don't think its impossible to fix it and
make it happen as well.
>
> but anyway, I get your view, but I'll just disagree :) not sure if we
should discuss and try to change each other's minds.
>
> cheers
>
>

-- 
--
May you, and all beings
be happy and free from suffering :)
-- ancient