Improvements/Wishes for the patcher

#178

You might consider adding a couple more XML tags (or additional properties for existing tags) to be used in the Parameter section of the object definition.
Taken some cues from HTML/CSS, how about

float left
float right
clear

Using these tags/properties, you could arrange controls in horizontal rows and specify where to start the next row. It would be a start, in terms of allowing more controls over object layout.
Note: you'd have to move the parameter label above or underneath the control, for this to work (but to be honest, I think it would look neater here, anyway).

I used to be involved in the development of a video performance software, that had a plugin format based on Quartz Composer. At one time, they experimented with a method to allow plugin developers to customise the layout of their plugins, and even add their own background image. Adding the ability for Axoloti custom object developers to add their own logo or branded background image might encourage more established programmers (i.e. those who already have an established brand) to get involved.

a|x

#179

It gonna look like nightmare IMO. Reminds me Jeskola Buzz in skinned mode:

machineview.jpg768x576 76 KB

#180

How about reserving a small area at one corner of an object for logo or something similar, as a compromise?

a|x

#181

can i suggest, this topic is about what to change.... rather than how to implement it.

Id leave implementation decisions to the the implementor, we all know about HTML/CSS/XML ... and we are pretty familiar with graphical environments (including Quartz Composer)

now... if you want to get into implementation, and start developing the code, fantastic... then we will definitely be happy to discuss with you options for implementations.. not in this topic, but in the developer category or github issues.

(honestly, the reason for not doing this stuff as yet, is not, not knowing how to do it, its about time and resourcess)

#182

I second this request! I also find it hard to read and tried in vain to zoom in, pleas make it so we can :smile:

#183

4 posts were split to a new topic: Poor performance with patcher on older machine

#184

moved to separate thread...

Parameter/inlet change functions
Parameter/inlet change functions
#186

A post was merged into an existing topic: Parameter/inlet change functions

#187

A post was merged into an existing topic: Poor performance with patcher on older machine

#188

Just thinking, would an alternative execution order be possible?

My first instinct in terms of visualising signal flow would actually be top to bottom, left to right instead of left to right, top to bottom. In other words: columns instead of rows. I've been becoming increasingly aware of the importance of the execution order and have been trying to lay out my patches accordingly, but it makes it harder for me to actually keep track of what I'm doing.

Now obviously this can't and shouldn't be a global setting as it would break all existing patches, I would instead propose it be a per-patch setting so you can decide at the beginning which way round it'll be. The original execution order would obviously be the default and what gets chosen if an older patch without this flag gets imported.

Does this seem possible?

#189

I fear a patch setting for an alternative execution order will increase confusion. I do plan to address execution order, and add graph-based sorting, but this is a deep change, and importing patches requires extra care in development.
First priority in development is getting the next stable release out.

#190

I think Quartz Composer calculates execution order by working backwards from the output.

a|x

#191

For Sub-Patches and Patch/Patcher objects, how about the option to right-click on an object inlet, and have the Patcher create an Inlet object of the appropriate type for you?

Going back to the Inspector idea, this would provide a useful mechanism for reordering and labelling inlets and outlets for a Sub-Patch or Patch/Patcher.

a|x

#192

I guess there would be a right-click contextual menu, with one of the options being to do the above.
Another option in the menu might be to set a pre-scale/interpolation equation for inlet values.

a|x

#193

A useful feature for saving ressources would be a context menu option for each parameter which would make a parameter constant. If a parameter is set to constat, it then would behave similar to an attribute.

For the generated code this would mean the following. Lets take the following dsp method as example:

public: void dsp (int32buffer & outlet_out,
int param_pitch,
int param_reso){
// ...

If e.g. parameter pitch would then be set to constant, the generated code would become:

public: void dsp (int32buffer & outlet_out,
int param_reso){
static const int param_pitch = 12345;
// ...

#194

I little feature-request:
how about being able to click on the title-bar of a patch window to go to the patch file in the OS? This feature is common on OS X, and is really handy! It could be implemented as a right-click menu that dropped down from the title bar, giving the option to go to the file, and maybe also to rename it.

I must say, the more I use the Patcher, the more I discover nice little touches, like the fact that you can double-click the titlebar to toggle the window to/from fullscreen.

a|x

#195

I think this has been mentioned before, but can we please have the window position, dimensions and active tab of the object editor recalled when it is reopened....?

I've been working on some custom objects, and frankly, the workflow of using the editor is.. not great.

Every time I want to test my object, I have to

  1. Save the object (no keyboard shortcut for this)
  2. Close the Editor
  3. Reload objects

Then, when I need to go back to the code, I need to

  1. Open Object Editor with the fiddly menu
  2. Resize the Editor window
  3. Use the arrows to increment down to the tab I want

There has to be a way to speed this process up. It's maddening, currently, I have to say.

Maybe keyboard shortcuts for all these steps would help.

a|x

#196

That's normal in Windows, I didn't realise it was a special feature of the patcher?

#197

Here's a thought: how about removing the requirement to close the Object Editor window before making a patch live, but simply removing the ability to save it while the patch is live?

That would help enormously.

a|x

#198

Oh, maybe it is...

I've never noticed it before, but it must be an OS-level feature on Macs, too, because I've just realised other windows do the same thing.

How embarrassing...

a|x