Patching guide

#1

yeah, I think the (main) user guide is misunderstood, its more a guide to UI than patching, and often beginners want a patching guide (which is why I recommend @janvantomme book) which it is not, and we haven't had any volunteers from the community to write one :wink:

a patching guide would be cool, though very time consuming to write it you want to go beyond the basics covered in the tutorial patches, also it really needs to be done by a technical writer (which I'm not :slight_smile: ) ... I don't know if you have every seen the documentation for Reaktor, its massive, probably over 1000 pages in about 3 or 4 manuals. that's just not doable for an open source project.

Beginner - where is CLDS? Struggling already
#2

As an alternative, Jan van tommes book is a good place to start, as you suggested.

But yeah getting back to making patching guides. I think a general knowledge of synths and samples, and especially modular synths can get you far. But I think it is the part that when you for example want an envelope from Axoloti fac.lib. you have to connect several objects to get a usable ADSR env. It is like a modular modular synth..... :slight_smile:

As you say Reaktor patching guide is 1000 pages or even more... This is just a lot.. And actually I also think it is a bit outdated... I think it would be MUCH better to have video tutorials.. And they are also a lot easier to make.. You can say and show more in a 2 minut video than you can write on several pages(exaggerating a tiny bit)... But yeah, som basics would be great to have in writing, which could be used as reference to the video.. After all most things I star learning these days starts on youtube.. And THEN moves on to the manual/documentation later on... :slight_smile:

But where should one start with writing documentation? Maybe writing more extensive notes in the helpfiles could be a start? That was one thing I noticed when getting started, that it would really help a lot with more notes in the helpfiles.

#3

@thetechnobear & @jaffasplaffa,
If you don't mind, I have an idea that might work for patching guide.
It is to use the "Sub Patches" as the guide.
So there is a section in the library for "Help" subpatches, but when you set them up, you do not add Patch Inputs and Outputs like you normally would, but then when selecting the help subpatch, it is then opened up showing the basic setup, and it only needs to show the appropriate objects, it won't need any more, then the user, can just copy and paste the objects into their patch and go from there. This way subpatches can be as simple or as complicated as you want, and note can be added to the subpatch as guidelines where required.
:grin:

#4

I am open for discussion about it.

One thing I like about using the helpfiles , is that EVERYTHING you need to learn is there all ready inside the patcher. No need for exiting the patcher or going online to read some documentation, all you need is right there in the patcher

@thetechnobear Maybe this should be separated into a new thread? I dont think I can do that.

#5

Ok split.

Sorry @Gavin , I don't really follow what you mean.
help patches are normal patches, it's pretty much the same model as used by max/msp.

Also I think we should be clear, some Ike the OP are saying examples patches are not enough, they need more guidance

Btw the community could improve help patches , (and tutorial ) and submit as pull requests, some are not great.

Help text similarly these are not really a guide for beginners, it's more text to help you use a particular object.

The object description is the place for this, but I'd agree it's not easy to edit, and I don't think supports markup

Perhaps it's best to keep the description short, and have a better 'supports' object in the help patches so they can be more elaborate ,I think this was the intention as this is how the tutorials are done.

Again, max pretty much does this

perhaps another issue, is the inlet/outlet descriptions are too vague , and putting this is the small text box is not really ideal.

Anyway I think al this is more a modern alternative to the old 'reference guide', rather than a guide on how to patch.

A patching guide, I see as something that teaches the techniques of patching , sure this is using some common objects, but also midi parameter assignment, presets ... and converting different use cases like synth building, fx , midi routing and sequencing.
I think this is often the missing link for beginners, partly what objects to get started, and how to combine them to solve.
Once you have that then you can explore more specific objects, where the help becomes important.

As to the form of the patching guide, sure text or video works - I'd agree I think many of us learn these day via YouTube.
Though we have had calls here for writtten documentation, so perhaps you can't please everyone.

The disadvantage of videos is, if the software changes you cannot update them, you have to reshoot - and shooting/editing/uploading videos can be pretty time consuming.

I will say the YT videos I've done for Axoloti don't have many views so I'm not inclined to spend much time on it

#6

Yeah, sometimes my thoughts get jumbled.

May if I break it down a bit better and add pictures...

Lets say I create a help subpatch for LFO trigger to a Demux.

I create a sub patch with the following setup.. saved as a subpatch exactly as shown..
without factory/patch/inlets or outlets..

Lets say someone wants to know how to add an LFO trigger to a Demux.
User that needs help goes to contributions or where ever it is kept, add it to their patch as follows..

User selects "Embed as patch/patcher" and it will open up the subpatch as per the first image which they can learn or even copy from etc..

This way it keeps the help in small steps rather than in full patch setup type scenarios.:grin:

#7

I dont mind helping w bit with this.

Actually there are a few small things that could be fixed also in objects. For example the minimum and maximum object have been switched around. Min object is actually a max object and vice versa. Also table/play, has issue with the pitch dial, it is inverted, when going lower in the pitch the pitch actually get higher and vice versa... This is easy fix, just change the - before the param_pitch to + then it works as supposed.

But I am up for making some of the help files a little bit more extensive.

Yep true, didnt think of that.

Understandable.

A while ago we also talked about community guidelines and i did write down something, but in the debate there was really many views and perspective on it I kind of got stuck in it. But writing some patch guide or tips in tutorials are a little bit more concrete and easier to approach. It is not so much related to opinions, more related to factual stuff :slight_smile:

#8

This also comes down to the the guy making the helpfile.

But in general, our sugggestions are pretty close. But for me to understand it right, do you mean that you want to put all the subpatches with tutorials into the com.lib? If so I think this can get really messy, having loads of " unfinished" or not working subpatchs in the library. IMO then it is better to have them hidden away in the helpfiles, which you dont see when vrowing the com.lib.

#9

This sums up my initial thoughts 100%. There seems to be a big gap between knowing nothing about coding/patching, and knowing a decent amount. That middle ground in between is very daunting, and filled with object/object/somethingelse/codename/tinytext, which is the complete opposite of what I'm personally used to dealing with in everything else I do in music (DAWs, synthesis, sampling, etc).

P.s. it has occurred to me that I perhaps bought a product that is far beyond my skillset, however I think the Ax could have some serious popularity if it was "dumbed-down" a little with some walk-thru's, at least to get people started. I also get this is hard as it's open-source, community driven etc. It's not like it's a $900 piece of equipment.

p.p.s dumb question: any way to increase the size of the text in the app? I have pretty good eyesight and find the patches are ridiculously hard to see what the hell the help sections are saying...

#10

I also think that it is a must to have a little understanding of synths, before going into modular world. But yes the gap between "regular music devices" as you mention is pretty hefty. But th good thing is eventually you can design your own stuff. When I work with plug ins and so on, i always think " why cant i do this and that?".. In axoloti you can test it and find out :slight_smile:

I remember when getting started here too. Had many stupid questions and frustrations. Just ask @thetechnobear, hehe :wink: Everyone can learn Axoloti if they want to. But if one prefer just to have something that works out of the box Axoloti is probably not the place to start.

But Axoloti can also be very simple if you just want to copy basic synth designs and so on. And do basic sequencing. This is pretty simple and doesnt take much more skill than using a Clavia modular synth or similar modular synths.

But as soon as you go into working with audio and tables and so on, it gets a bunch harder and there are many steps to get ones head around. And if you want to code your own objects. What I am trying to say is that there are many levels in axoloti.

#11

@Gavin , that's a bit like 'snippets' in Max... which you could already kind of do, personally, as subpatches in your objects directory.
for the library, I don't see much advantage over just saving these as objects (axs), with inlets and outlets, where could then give proper descriptions etc

I see it as problematic for help files though, since ideally a help file, concentrates its focus on demonstrating the object at hand, rather than be useful.
so I think its two different things.

just checked the code, looks ok to me... will test next time Ive an axo to hand.
(bare in mind, at the moment, we wont change behaviour of factory objects, due to this breaking users patches)

don't get me wrong, I do think YT videos have merits, perhaps I might do a series one day when Ive a bit more time.

a bit unrelated, or not... I have to say, I don't tend to look at help files...
I find it so quick to patch up an objects into test patch with ctrls -> obj -> disp/scope that I do this, to see how an object works/responds to parameters etc. often I then copy bits of this test patch, out to the patch I'm developing... so in this regards its a bit like @gavin suggestions.

actually, it probably is a bit deeper than that, this goes into my entire workflow for development (patch, but also object, and c/c++) , I tend to make small self contained code segments/patches, and test this, and then combine/evolve these into the complicated patches/code. I take this approach, as its not only systematic, but its also helps reduce bugs (and the complexity of bugs where they exist)

so when I'm recommending people start small, and be hands on, explore - this is because this is the way I approach things.

@mlbstrd I'm sure you'll get there, but being for sure it needs a bit of dedicated time, and an appreciation that you'll need to start with 'mickey mouse' patches first, and work your way up to a CS80 emulator :wink:

@jaffasplaffa is right, probably the two most common issues/questions, are around 'execution order' and tables... neither are 'hard' but you need to get the basic concepts down well, otherwise they will keep tripping you up. the good news is, neither tend to come up till a bit later in your explorations .. usually just about when you think you understand it all - they hit you :wink:

... these topics really could do with a tutorial video, unfortunately, they need to be later in the series, as you need all the basics to be in place first.

this we hope will be back in the next version ... we did have zoom in 1.0.12 but we had to roll it back, due to performance issues, unfortunately the issue was quite deep, so it was not just a matter of fixing a bug, its part of a more fundamental development.

#12

This is exactly where I'm getting stuck. I'm a new user hoping to do mainly audio manipulation from the audio input, ideally sampling, scrubbing, chopping, etc. Wrapping my head around tables and initializing them is proving pretty confusing, and most the examples I'm finding in tutorials are about building synths, which is a) not actually what I want to do with axoloti, and b) much more straightforward than tables and live audio manipulation.

I have a decent technical writing background, so hopefully once I've gotten my feet wet, I can start writing the documentation I wish I could find now.

#13

If you are stuck you should ask in the forum. Most of us are willing to help with whatever issue comes up :wink:

#14

The value on the left is set to 52, but it stops at 32, which as I understand it makes it a max value. The value can maximum be 32.
And the same with the right side. The value is set to 5.5 but it stops at 15, which makes it a minimum object, since it the minimum value send out is 15.

About the pitchknob.. If fixing, this kind of "breaks" patches... I think if there is changes done to these objects, especially the table/play, it would be a good idea to announce it in some way. It is a widely used object and this could cause many frustrations with patches suddenly sounding different.. Maybe flagged post or something? I dunno, just thinking out loud.

#15

yeah, we need to be a bit careful here...
of course some things in DSP are more complex (like audio manipulation) than others (synths/sequencing ), its not just harder in Axoloti, its also harder in max/pd/reaktor too - especially if you want glitch free audio.

I think though there are quite a few objects in the community library to handle more things, with having to do it yourself, though I don't really follow these developments... as there so much new stuff going on :slight_smile:

coming back to the topic though, it would be interesting to know what the topics should be in a patching series. as you, say, it needs to go beyond simple subtractive synth creation.

so how about a list of videos that would be created ...
now I'm going to set some rules, to keep this achievable.

imagine a series of video tutorials.

each tutorial is a maximum of 15 minutes, so a topic has to be self contained/explained in this time, this includes explanation of the topic/subject, and building one or more patches.
(this is a big constraint, but necessary, views on YT of videos over 15 minutes, drop off dramatically!)

the videos can 'build on each other' but need to be self contained, i.e. video 5 can depend on video 3 being watched. though dependencies should be minimised, except the first intro video, this means views could 'pick' topics they are interested to watch.

the aim is not to build fully functional synths/fx/seq/samplers... theres no way you can do that in 15 mins, its to show the concepts, hopefully after watching a number of the videos you could build something more complex. similarly simplifications have to be made/assumed....
(we could have a post on the forum about each video, which would allow users to discuss/build upon the concepts of the video, talk about the simplifications)

practical, frankly, I don't think 15 minutes on tables without a practical example is very interesting, it'll be way too dry, and put people to sleep.

I'm thinking something like dude837 has done for max...
see https://www.youtube.com/user/dude837/videos

thoughts...

basic idea is an agreed topic list, that fills these criteria, with a short description of what each episode covers, and the demonstration patch it will be.
(again, I repeat, no I'm not going to be a korg volca sample or octatrack in a video :wink:)

#16

no, both are correct.
32 is the lesser of 52 and 32, i.e. the minimum value of the two. similarly 15 > 5.5 , so is the maximum of the two values.

I'm not quite sure of your understanding, but this is consistent with min/max operations in C/max/pd etc

#17

As i undestand a minimum value, it should be set by a constant, which is the second input. That one is set to 32. So they first input should not be able to be less than 32...

But works the other way around:

When I turn the value know, it wont go above the second input, which is 32. it stops at 32, so 32 is max.

Probably my understanding of it that is not correct. But to me logically, what I just wrote, makes more sense and that is how I use a minimum and max function. If i dont want o exceed 32, I set a max value of 32 and then what ever you feed that input, it wont go above that value. And to use it like that you have to use the opposite version.

EDIT: But after playing with it now, I see that what the minimum object actually does it letting the signal of the input with the lowest value pass through. Which also makes sense. I just didnt think of it like that.

#18

Ha! have watched many of his videos lately, learning a it about making video sync to the beat of an audio signal. Nice videos

#19

yeah... its one of those things, if you've used other similar things, its 'natural' , but of course, if you have no reference point I can see you might have different expectations. this is where its important the descriptions/help patches are correct.

of course where possible Axoloti is consistent with other conventions, it helps when users come from different environments.

(flip side is, the more you learn in Axoloti, the easier you would find using PD/Max/Reaktor!)

#20

Yeah I found what I needed so it wasnt a problem for many seconds :slight_smile:

Yes I have been going back to learn PD lately and it helped a lot to have the visual aspect of Axoloti in my backhead while working with PD.. PD is just so...... "cold" on the visual side when you start out. I need to see what I do, then I learn much faster.

Reflections on Pure Data