Patching guide

#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
#21

I found a video series on YouTube by LWM. Learning synthesis with pure data, where he builds a typical synth in pure data and explains general points in DSP and synthesising sound. He's a bit like my old chemistry teacher, the intro has that 80s kinda new age tackiness and his videos aren't very short, yet I found them more resourceful than others to pure data.

I have send him a mail about the axoloti, he seemed excited, asked a lot of questions. That was a few months ago. I hope he's got one now and has joined the community already. I find he'd be awesome to do videos on how to patch synths using the axoloti, because he seems very knowledgeable, and that could help a few newbies.

We could collect a few links pointing towards learning resources and have them in a post in user guide, we could divide it into sections of specific topics. I don't know if anyone already has pointed out to make a wiki. It's probably a bit of work, I would mind helping with it tho.

#22

mod note: moved pure data thoughts to new topic, so as not to side track this thread, and possibly deserves it own anyway

2 posts were split to a new topic: Reflections on Pure Data

#24

@thetechnobear: it does take quite an effort to build something like a wiki for one person, and the user guide section is actually good enough. I shall see what I can come up with.

Another idea could be posting challenges that are broader in their assignments (make a patch about "green", make something with only 2 sine waves, etc.) and easier to accomplish by members of different skill levels.

...just having random thoughts.

#25

I still believe small helpfull tips can be extremely resourceful, they can take a lot less time and effort to setup, and it can often be small steps that can get you over the humps. Its just a matter of how best to implament.
:grin: