@le26muko said:

My bandmate is pushing me to sell it, and I am trying to explain to him that it does not work like that in this community.

yeah, you know your bandmate doesn't know how open source works

So, yeah, what you're asking about is really highly frowned upon I would say. Of course you're free to do it, but it's not something people actually do or something that goes in this community.

On the other hand, this is such a MAX thing to think and do, and if you want that I'd really suggest you worked with that. People over there sell externals, patches and MAX is better at making apps that are actually just patches.

What Pd people do is ask for donations. I do have a patreon by the way
https://patreon.com/porres

I've been doing cool stuff that people really use and find it useful and never thought I could charge for any of that and, of course, I can't live and base all the work that I do with Pd based on how much I make with Patreon, it's not for this that I do what I do... Pd is more about sharing, contributing, doing voluntary work and being "free" (as in speech, not as in beer).

What people that use Pd also do is create an app with libpd or something, do stuff that is based on Pd but it's a standalone thing on its own, and you can sell it in an app store or something...

Check for the license though. Pd's license is permissive, but most etxernals will use GPL, which won't allow you to sell. On the other hand, my stuff has a very permissive license and you can "do whatever the fuck you wanna do" as one of the clauses will say.

All I'd say is, if you make work and you get money and you use my stuff a lot and you like my work and you feel like motivating me, consider donating something via patreon.

I'm not saying that's the case for you exactly, I'm just telling how I stand on all this as to give you an example on the matter.

cheers

@earlyjp There might well be a better way than the two options that I can think of straight away.

You could play the audio file from disk, and send a bang into [delay] objects as you start playback, with the delays set to trigger the messages at the correct time.
I am not sure how long a [delay] you can create though because of the precision limit of a number size that can be saved in Pd. You might need to use [timer] banged by a [metro]

Or as you say you could load the file into RAM using [soundfiler] and play the track in the array using [phasor~] and trigger the messages as the output of [phasor~] reaches certain values.
Using [phasor~] the sample will loop though.
To play just once you could use [line~] or [vline~]
You would need to catch the values from [phasor~] [line~] or [vline~] using [snapshot~].
[<=] followed by [once] would be a good idea for catching, as catching the exact value would likely be unreliable...... once.pd
The same will be true if you use [timer] as the [metro] will not make [timer] output every value.

Again, number precision for catching the value could be a problem with long audio files.

Help for the second method....... https://forum.pdpatchrepo.info/topic/9151/for-phasor-and-vline-based-samplers-how-can-we-be-sure-all-samples-are-being-played

The [soundfiler] method will use much more cpu if that is a problem.
If there is a playback object that outputs it's index then use that, but I have not seen one.
David.

I have a vline going into a cos~ and into a tabwrite~ plottercos ( range -1 +1 ) for plotting . tabwrite~ ramp has a range 0 +1
Upon a few bangs , the cosine is completely out of phase
I tried tbb first into vline , then into tabwrite ~ and vice versa but the issue still remains
You can clearly see in the second window ( vline~ without cos) that vline has a value 0 < upon it's start phase
Weird

Hi! This has gotta be the biggest update ever. geez... there's too much stuff, and I just decided to stop arbitrarily cause there's still lots of stuff to do. Ok, here goes the highlights!

This is the 1st multichannel (MC) aware release of ELSE (so it needs Pd 0.54-0 or later)! There are many many many objects were updated to become MC aware: 42 of them to be exact. There are also many many new objects, and many of them are MC capable, 20 out of 33! Som in total I have 62 objects that deal with MC... that's a good start. More to come later!

Note that 4 of these new ones were just me being lazy and creating new mc oscillators with [clone], I might delete them and just make the original objects MC aware... so basically these new MC objects bring actual new functionalities and many are tools to deal with MC in many ways, like splitting, merging, etc...

With 33 new objects, this is the first release to reach and exceed the mark of 500 externals, what a milestone! (This actually scares me). We now have 509 objects and for the first time ever I have reached the number of examples in the Tutorial, which is also 509 now! But I guess eventually the tutorial will grow larger than the number of externals again...

Since the last release, ELSE comes with an object browser plugin, I have improved it and also included a browser for Vanilla objects. I think it's silly to carry these under ELSE and I hope I can bring this to Vanilla's core. see https://github.com/pure-data/pure-data/pull/1917

A very exciting new object is [sfz~], which is a SFZ player based on 'SFIZZ'. This is more versatile than other externals out there and pretty pretty cool (thanks alex mitchell for the help)!

I have created a rather questionable object called [synth~] which wraps around [clone] and [voices]/[mono], but I think it will be quite interesting to newbies. It loads synth abstractions in a particular template and makes things a bit more convenient. It also allows you to load different abstraction patches with dynamic patching magic.

[plaits~] has been updated to include new 8 synth engines with the latest firmware. Modular people are happy... (thanks amy for doing this)

One cool new object for MC is [voices~], which is a polyphonic voice manager that outputs the different voices in different channels. If you have MC aware oscillators and stuff this allows you to manage polyphonic patches without the need of [clone] at all. This is kinda like VCV works and it opens the door for me to start designing modular inspired abstractions, something I mentioned before and might come next and soon! So much being done, so much to do... What an exciting year for Pd with the incredibly nice MC feature!

There's lots more stuff and details, but I'l just shut up and link to the full changelog here https://github.com/porres/pd-else/releases/tag/v1.0-rc9

You can get ELSE from deken as well. It's up there for macOS, Windows 64 bits, Linux 64 bits and raspberry pi. Please test and tell me if there's something funny.

Cheers!

Chees.

@Dizzy-Dizzy Try putting this.......... one.pd just after all the bangs that are sticking.
They will all let just one message pass... and they can all be reset at the same time by sending any message into a [send reset]..... just a temporary measure to see what is going on.......
Maybe you can then verify that it is an audio hang rather than repeat messages from the arduino switches.
If the bang still sticks but audio is good then you have repeat messages.
If the audio still glitches then it is back to other solutions.

It is likely that reducing USB to 1.1 means that you have a lower rate of messages from the arduino switches as they bounce, and so bigger jumps between messages.
As you are not likely to push the same button again within 2 tenths of a second maybe you should lock messages out for 200ms in [button_debounce_time]
What do you have inside that abstraction?

Try replacing [vline~] with [line~] as you are just doing a fade in and out and [line~] is good enough for that.
In fact [line] would be good enough and if it "zips" you can set a finer grain than the 20ms default.
[vline~] is more expensive...... scheduling across block boundaries, and the [vline~] are doing their stuff just as you write and read files.

Replace the audiolab highpass filter with [hip~ 120]....... again, likely to be less expensive.
As a last resort get rid of [realtime] and just use [delay 5000]
But really the patch (if we are seeing it all) is not very heavy so I would put my money on those switches.....

David.

@ddw_music fudi is so simple it makes it really easy to send stuff to pd from other programming environments like a lua or python interpreter. (or even bash for that matter)

you can just pipe text into the pdsend program and viola
but OSC is probably a good habit to get into using as well

@whale-av said:

@Balwyn Maybe [vline~] and [tabread4~] would improve the precision?
David.

Thanks David! that made all the difference, in fact just changing [line~] to [vline~] did the job with 197MB no problem.
vline-play.pd

Edit:
i also added -maxsize 2e+09 to the read message, something you recommended years ago

Simulates vline~, but outputs control messages like [line].

You're welcome

vline-hjh.pd

hjh

@nicnut

Instead of relying only on [metro]
with it's control rate resolution swing

for a steady clock,
without testing, I'd say
-----LATE EDIT: THE FOLLOWING IS NOT NECESSARY:---------
calculating with the output of
[realtime]
or a sample-counter and [samplerate~]
or [timer]
a message
for [vline~]

should do the trick.

Composing the delay-time-message for [vline~]
by substracting the expected exact time
from the actual time ( at block boundary )

----USING [vline~] WITH ANYTHING (LIKE [metro] JUST WORKS-----

There are many ways to build messages and trigger [vline~] accurately.
Am interested in what you come up with!

Also the time-stamping t3 objects in the iemlib could help!

@morpheu5 Your clones are identical. There are two incoming messages that change their operation.
[next $1( and [r $1-grainSpeed].
But [s $0-grainSpeed] sends to all of them so they all have their speed settings changed at the same time as a note is played (except that they do not without the "cursed" bang..)

With the cursed bang they are all updated for an incoming note...... but all the [vline~] are restarted causing an overload.
Without the cursed bang none are updated until the metro bangs again....... but there will be an indeterminate delay until the metro bangs........ during which time the tail of the previous grain will still be playing the previous note..... and then none of the others will be updated......

Assuming you want all the grain tails to be updated by the note but not be restarted..... (that is how it looks at the moment....... Monophonic.... if not then everything below is untrue).......

........ you will need to bang [vline~] only from the [next $1] message and modify the output of [vline~] before [tabread4~ $1-grainData] with a [x~] for all the other clones..... the value for the [x~] being the relationship between the current and the previous note.

..... And the new note needs to bang the [next $1( message...... not the [metro]

BUT you will not want the multiplier for the newly banged [vline~]....... and your clones are identical...... aargh.

SO in fact you need to get the grainSpeed into the clone as a modifier of the output of [vline~] and not as part of it's received message (so that they all change)....... and only bang one clone to restart one [vline~] at the same time through the [next $1] message..
Doing that you will only need to set the modifier as a value for the note and you will not need to mess around with relative values between notes.......
I think that is it in summary.....
David.