Skip to content
This repository has been archived by the owner on Oct 13, 2023. It is now read-only.

Alternative to [fexpr~] #21

Open
reeson46 opened this issue Jun 9, 2019 · 11 comments
Open

Alternative to [fexpr~] #21

reeson46 opened this issue Jun 9, 2019 · 11 comments

Comments

@reeson46
Copy link

reeson46 commented Jun 9, 2019

Hello. I'm learning PD and doing Andy Farnell's patches from his book. I want to use some of the patches in the game. I'm stuck on compiling this patch that has [fexpr~] object in it. Is there an alternative? I saw that Heavylib has this [hv.epx] object, but I'm guessing it's not the same.

@giuliomoro
Copy link

giuliomoro commented Jun 9, 2019

that's [hv.exp], and it's an exponential function, replacement for [exp~].
@Simon-L did a static [expr~] compiler (see here) a while back, but I don't know if (or think that) it supports [fexpr~]. Ultimately, you may be better off trying to replicate the behaviour you are looking for by using lower-level Pd objects (e.g.: [rpole~] and [rzero~]), if at all possible.

@reeson46
Copy link
Author

reeson46 commented Jun 9, 2019

I see. Well, I'm very new to all this, but as I'm looking at Simon's patch, it's not for the audio signal. The whole object that I'm trying to replace is [fexpr~ $x1 - $x1[-1]]. I don't know what exactly this expression does.

@giuliomoro
Copy link

check Pd's help patch for [fexpr~]:

The [fexpr~] object has exclusive variable types, defined as:
- $x#[n]: an input audio sample from inlet # indexed by 'n'
- $y#[n]: an output audio sample from outlet # indexed by 'n'
where 'n' for $x# has to satisfy: 0 => n >= -vector size
and 'n' for $y# has to satisfy: -1 => n >= -vector size

It doesn't actually specify what $x1 means, but I guess it is the same as $x1[0]. So $x1 - $x1[-1], seems to be doing the same as [rzero~ 1]. To test that I made this patch:

Screen Shot 2019-06-09 at 21 11 18

click the bang and check the console: you will see that the outputs generated by the [rzero~] and [fexpr~] are indeed the same.

@reeson46
Copy link
Author

reeson46 commented Jun 9, 2019

Thank you so much. It works :D

@reeson46
Copy link
Author

reeson46 commented Jun 9, 2019

I just tried to recompile with [rzero~ 1] and I get this message: [rzero~] accepts only signal input. Arguments and control connections are ignored.

@giuliomoro
Copy link

giuliomoro commented Jun 9, 2019

then send a signal to the right inlet of [rzero~] instead:

[<your stuff here>]
|
|     [sig~ 1]
|     |
[rzero~]

@reeson46
Copy link
Author

reeson46 commented Jun 9, 2019

Although I get the same message, it's all good in wwise now. Maybe the sound that is coming from that part is a little bit louder, but nothing I can fix with h_param in wwise. Thanks again 👍

@giuliomoro
Copy link

Did you remove the argument 1 from [rzero~1 ] ? Or maybe that message always comes up every time you use [rzero~]

@reeson46
Copy link
Author

reeson46 commented Jun 9, 2019

Yes, I did. Here's the patch. [rzero~] is in "flowing_water_generator"
runnin_water.zip

@reeson46
Copy link
Author

Also, I just remembered. When I compile for wwise from Vs2015 folder, sometimes I get this warning: WwisePluginEngineParams.cpp(90): warning C4065: switch statement contains 'default' but no 'case' labels
The patch works fine in wwise. but still, sometimes I get this warning, and sometimes I don't.

@giuliomoro
Copy link

that warning is not a problem. It's the Microsoft compiler (or Visual Studio) who are needlessly pedantic.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants