Mark Durham

I've designed a granular synth which I want to be able to add into a package of clippings, then right click and 'paste from', basically the same way the clippings from BEAP work. Trouble is that each instance of my grain synth need a single argument to differentiate the buffers. I've copied the way BEAP seems to work with a lone BPatcher inside the patch, have named everything #1, set Embed patcher in parent, set a scripting name... not working. Maybe there is a way to set the argument the same as the scripting name?

pasting-from-max-packages-with-unique-arguments

(bump) Let me know if this is unclear. I can explain more fully if necessary.

I *think* it would be more logical if it worked only if you don't embed the patcher in parent. Did you try that?

I haven't, just because I've been trying to follow the way BEAP seems to work. I did just see that the patcher for the BEAP granular osc is kept in the folder misc within the package, but the odd thing is that when you inspect the bpatcher containing the patch it does not display anything under 'patcher file' or an argument, yet it still works (see picture). I'll try not embedding it, but I've got a few modules I want to share and it seems that a package is the best way to do this. I just can't find anything in the documentation about how to do it.

Hm, I see.. this really is puzzling, I'd also like to know how that works. anyway:

I’ll try not embedding it, but I’ve got a few modules I want to share and it seems that a package is the best way to do this. I just can’t find anything in the documentation about how to do it.

I think there is no problem about sharing, also when not embedding. You can follow the same scheme. I actually prefer to not embed things, it's a bit more tidy I believe. Also, obviously all your patches using the instance will be updated if you find a mistake. And if you want to modify it when you pasted it in, you can still choose to embed it for certain projects. Just a couple of random thoughts not really related to the problem :)

 I’ll try not embedding it, but I’ve got a few modules I want to share and it seems that a package is the best way to do this. I just can’t find anything in the documentation about how to do it. 

I think there is no problem about sharing, also when not embedding. You can follow the same scheme. I actually prefer to not embed things, it's a bit more tidy I believe. Also, obviously all your patches using the instance will be updated if you find a mistake. And if you want to modify it when you pasted it in, you can still choose to embed it for certain projects. Just a couple of random thoughts not really related to the problem :)


usually I'd just create a patchers folder inside the package folder containing the patches, and a clippings folder containing patches having a bpatcher accessing the patches in the patchers folder. patcherpatches. if that helps.

Thanks Woyteg for your thoughts. I think it's just a nice thing for a user of the modules to be able to drop 2-3 in and start using them straight away, without working out they need to set the argument for each individually first. It kind of makes no difference to me, but will make it more usable for others. It's a bit of a different way to use Max, but I think it's what Max needs - a way to create stuff quickly with a set of building blocks. I like to spend lots of time creating intricate devices, but I also like to just create sound, and that is sometimes easier to do with knobs rather than patch cords and arguments.

Is there anyone at C74 who knows the answer to this...? I'm surely not the only person to have tried to do this!

Thanks Woyteg for your thoughts. I think it's just a nice thing for a user of the modules to be able to drop 2-3 in and start using them straight away, without working out they need to set the argument for each individually first. It kind of makes no difference to me, but will make it more usable for others. It's a bit of a different way to use Max, but I think it's what Max needs - a way to create stuff quickly with a set of building blocks. I like to spend lots of time creating intricate devices, but I also like to just create sound, and that is sometimes easier to do with knobs rather than patch cords and arguments. 

Is there anyone at C74 who knows the answer to this...? I'm surely not the only person to have tried to do this!


Hm. I think there is some misunderstyanding here. I know what you are talking about, I also create my own set of BEAP/Vizzy like modules for some time now.

This is also one reason why I had several complaints in the past:

-a better way to interface clippings, clippings in the palette, maybe with their own little icons, patcher descriptions showing up, patcher descriptions in the autocomplete dropdown etc..

Anyway, I don't get your problem, you can start using them right away, why do you need them to be embedded?

Hi!
Hm. I think there is some misunderstyanding here. I know what you  are talking about, I also create my own set of BEAP/Vizzy like modules for some time now.
This is also one reason why I had several complaints in the past:
-a better way to interface clippings, clippings in the palette, maybe with their own little icons, patcher descriptions showing up, patcher descriptions in the autocomplete dropdown etc..
Anyway, I don't get your problem, you can start using them right away, why do you need them to be embedded?


So the easiest way to explain it is looking at BEAP. If you paste in (by right clicking, paste from > BEAP) 2 granular oscillators, you then can load a sound file into each individually, no setting arguments or anything like that. I want to know how this works.

With the granular oscillator I've designed, if I save it as a clipping it still needs an argument for more than one to be active at any one time, otherwise I load a sound into one and it loads into both - as they are effectively sharing a buffer.

I could be missing something really simple here as I'm totally new to packages, but I've tried everything I can think of!

Ah, we've been at crossed wires have we. 

So the easiest way to explain it is looking at BEAP. If you paste in (by right clicking, paste from > BEAP) 2 granular oscillators, you then can load a sound file into each individually, no setting arguments or anything like that. I want to know how this works. 

I could be missing something really simple here as I'm totally new to packages, but I've tried everything I can think of!


Ah, we’ve been at crossed wires have we.

:) hopefully we don't still are. Alright, got you. What i was suggesting is:

You want the #0-buffername magic to happen inside a bpatcher. right? What I am telling you is, I have no idea how the BEAP guys did it, since this should not work when the bpatcher is embedded. I am using this all the time, but it only works if the bpatcher is not embedded.

Which makes sense, since the #0-magic is supposed to happen inside abstractions (=not embedded) but not inside subpatchers (=embedded.).

That is why I am asking you why you want to embed the bpatchers.

Ah, we’ve been at crossed wires have we. 

:) hopefully we don't still are. Alright, got you. What i was suggesting is:
You want the #0-buffername magic to happen inside a bpatcher. right? What I am telling you is, I have no idea how the BEAP guys did it, since this should not work when the bpatcher is embedded. I am using this all the time, but it only works if the bpatcher is not embedded.
Which makes sense, since the #0-magic is supposed to happen inside abstractions (=not embedded) but not inside subpatchers (=embedded.).

That is why I am asking you why you want to embed the bpatchers.


In all of the above embed= bpatcher with its attribute 

 set active(just to avoid further misunderstandings)

In all of the above embed= bpatcher with its attribute embed patcher in parent set active(just to avoid further misunderstandings)


The plot thickens - If you open a new view of the from bpatcher inside bp.Granular, if you then lock and unlock the patcher the #1 changes to 1005 on all objects (see pictures). the question remains where the 

 came from.. presumably this number is generated individually for each instance? Though if I open two 'new views' the number is 1005 in each.

The plot thickens - If you open a new view of the from bpatcher inside bp.Granular, if you then lock and unlock the patcher the #1 changes to 1005 on all objects (see pictures). the question remains where the 1005 came from.. presumably this number is generated individually for each instance? Though if I open two 'new views' the number is 1005 in each.


ok I thought you knew that. #0 used inside an abstraction is generating a unique random number.

If you go- new few, you see it loaded as an abstraction. Therefore what originally was written #0, is now a random number.

If you go further and press -> modify read only -> unlock, you end up editing the original. You have not an abstraction in front of you anymore, wich is the reason for the #0s popping up again.

To make a long story short: use #0 inside abstractions to make unique things (contexts such as send receive networks, buffers etc.) inside an abstraction. Or a bpatcher (not embedded) for that matter. All clear now?

Though if I open two ‘new views’ the number is 1005 in each.

Make two instances of your bpatcher and open each the 'new view of' way. There will be different numbers. That's the whole point. We can have many views of a single patcher(which you did). That's why the numbers where the same. Having multiple views of the same patcher is extremely hand when working on interfaces btw.

ok I thought you knew that. #0 used inside an abstraction is generating a unique random number.
If you go- new few, you see it loaded as an abstraction. Therefore what originally was written #0, is now a random number.
If you go further and press -> modify read only -> unlock, you end up editing the original. You have not an abstraction in front of you anymore, wich is the reason for the #0s popping up again.
To make a long story short: use #0 inside abstractions to make unique things (contexts such as send receive networks, buffers etc.) inside an abstraction. Or a bpatcher (not embedded) for that matter. All clear now?

Though if I open two ‘new views’ the number is 1005 in each. 

Make two instances of your bpatcher and open each the 'new view of' way. There will be different numbers. That's the whole point. We can have many views of a single patcher(which you did). That's why the numbers where the same. Having multiple views of the same patcher is extremely hand when working on interfaces btw.
cheers!


Ah... that explains it. I've always used #1 which (now obviously) is argument 1, but I did not know that #0 generated a random number. Makes total sense now, so all I need to do is rename all my object #0 and i should get the same behavior.

On your last point 'Having multiple views of the same patcher is extremely hand when working on interfaces btw', how so - in what situations is this useful?

Ah... that explains it. I've always used #1 which (now obviously) is argument 1, but I did not know that #0 generated a random number. Makes total sense now, so all I need to do is rename all my object #0 and i should get the same behavior. 

On your last point 'Having multiple views of the same patcher is extremely hand when working on interfaces btw', how so - in what situations is this useful?


Still I wonder how the beap guys did it with the embed attribute set. If that hadn't been the case our confusion wouldn't have taken so long I think :)

If you have any patcher open and want to design it's gui, you can go view-> new view.

that way you can look at your patcher in presentation mode and edit mode at the same time, or do tiny sh*t in GUIs really detailed being zoomed in a lot, while having a few at normal zoom at the same time to see the bigger picture. Also when you have overlapping Gui elements in pres. mode, you can select them in the othert window in edit mode etc etc..

about views:
If you have any patcher open and want to design it's gui, you can go view-> new view.
that way you can look at your patcher in presentation mode and edit mode at the same time, or do tiny sh*t in GUIs really detailed being zoomed in a lot, while having a few at normal zoom at the same time to see the bigger picture. Also when you have overlapping Gui elements in pres. mode, you can select them in the othert window in edit mode etc etc..


Yes, I suppose that question still remains. I don't think will affect me now though, as like you said earlier (and this now makes more sense) I don't really need to embed my patchers.

about views - that's useful, and makes sense. That's two really useful things learnt today! It's actually this sort of stuff I find quite difficult to learn in Max, especially being self-taught and from a non-programming background, people naturally talk about the exciting stuff more than the functional side of things!

Yes, I suppose that question still remains. I don't think will affect me now though, as like you said earlier (and this now makes more sense) I don't really need to embed my patchers. 

about views - that's useful, and makes sense. That's two really useful things learnt today! It's actually this sort of stuff I find quite difficult to learn in Max, especially being self-taught and from a non-programming background, people naturally talk about the exciting stuff more than the functional side of things!


Not exactly re-opening this! But just for the record, I've got to the stage where the device is nearly finished, and the reason all along why I've needed the bpatchers embedded is to save all the device settings. So if you create a patch with a set of BEAP modules, the settings are automatically saved with the patch (even down to soundfile with the granular osc). This can only work if the patchers are all embedded (I think).

I'd still really love to hear from anyone who worked on BEAP to clarify how this all works...

Not exactly re-opening this! But just for the record, I've got to the stage where the device is nearly finished, and the reason all along why I've needed the bpatchers embedded is to save all the device settings. So if you create a patch with a set of BEAP modules, the settings are automatically saved with the patch (even down to soundfile with the granular osc). This can only work if the patchers are all embedded (I think). 

I'd still really love to hear from anyone who worked on BEAP to clarify how this all works...


Pasting from Max packages with unique arguments