Is there a way to organize these libraries? I want to move the individual things into different folders so I don’t have 100 folders. I would like to move hardware into hardware, ect., create new folders, rename the pieces in a way I can actually find them.
I found everything that was downloaded in the lib folder but any changes to the location or structure just removes it. I am assuming it is written in some sort of database. Can it be changed? What are my options?
There is no database. If it exists in the __lib__ folder, it exists as a library; otherwise it cannot be found.
Lousy workaround: I suppose you could rename the username folder to something that would be more meaningful to you, but then it would not be obvious what the source of the library is, so updating it will be difficult. Maybe replace username with hardware, then rename library to username_library? Either way, you have to delete old & rename new each time you update…
to add something else, if you download an example, xod re-downloads the original library and if you want to share something with someone, it will no work if you do not have your library.
I tried renaming folders and moving objects. They just disappear. The new folder I made doesn’t show up.
only take names with lowercase, for example my-lib or mylib01
Ok I moved everything from the downloaded lib folder to a new one outside the folder structure. I copy An object Folder from whoever, joystick and paste it into the xod/common-hardware folder. It does show up in the correct folder but also installs the original person folder and a duplicate. It shouldn’t be this hard to organize files. This is crazy.
if the node is composed it will depend on another library and it will be downloaded. So that does not happen you have to disconnect the internet and manually repair each node, with some editor. If it just starts I do not recommend making big changes because xod will not work correctly.
Also, if there is an improvement in the nodes, it will not be possible to access them as Gweimer said. And with 10 nodes it is easy to correct but with 100, 200 or more it will be very complicated. I have everything customized, but I’ve spent a lot of hours, and it was before the library indicated the error in red. Now it’s easier
It is difficult for me to find things when I don’t know exactly what I am looking for. With all of the downloaded libraries, everyone has a mixture of different types of objects under them. How are you supposed to keep it straight? Seems like there would be a way to give it a display name or something so you can organize it. It just a big mess. Like organizing your tool box by brand and not by function. Wrenches should be with wrenches. I get that it has to be updated but there has to be a way for the program to link to the file in a different location or folder name.
I think you have to dedicate time to know the nodes, library by library. Altium software design for pcb is the most complete but their libraries require a large study to use them. As I said before, I have modified everything but with hundreds of hours and after having read the entire forum, there are still things that I still need to learn how they work.
Use the node search function instead of searching through each folder and things will be a LOT easier. Double-click in the workspace and the search menu comes up. Start typing to find any matches (like “lcd” to find all nodes related to LCDs).
Trying to move shared libraries into other folders is going to make any of your projects that use them broken for anyone else, you will not have the libraries used by anyone else’s projects, and it will break any libraries trying to re-use the libraries you have moved. (besides not being able to update any libraries without repeating the whole process from the beginning)
If you know what your looking for search is good, but for a noob it’s not. You should be able to sort and rename. Maybe make a button bar.
I think a solution could be to put an alias, I do not know if it’s something feasible, we should see the opinion of @nkrkv.
XOD goes a pretty standard way of dealing with additional reusable items (the libraries). The building block is a library which is organized in a way its author thinks will work best, without any intervention of developers, moderators, etc. Otherwise, if we’ll try to enforce some names, structures, categories, etc, things can go even more complicated.
If you’d like to re-organize the set of libraries you have, one option is creating yet another library with nodes having “proper” names. Each such node might be a trivial wrapper around a node provided in another library.
I see your wrenches-to-wrenches analogy, and I wonder what structure are you willing to get? Would you provide a couple of specific examples telling what should go where? I wonder because the practical usage requirements can bring some useful ideas.
I have basically added every library from everyone I could find in the libraries area that I could possibly use. Which leaves me with a massive mess of crap where I can’t find anything unless I know the name of what I am looking for.
So when I add a library from whoever. Whoever’s library has 2 new hardware things, a unit changer, new bits, and a new core function. I just want to be able to grab that folder or node and move them to their xod folder. Wrenches with wrenches not a drawer for each brand of tool and a tool box with 37 drawers. This needs to be more practical and user friendly. Toolbox with 6-10 drawers organized by function. A drawer for screw drivers, drawer for wrenches, ect. I just want to be able to find it and know what it does from the name without having to know electronic gates. It should be simple and easy to understand.
From a program perspective the easiest thing to do is make the project browser window in xod not so literal. You should be able to to make new folders, name them whatever you want, move other folders inside of another folder, rename nodes, ect. Everything would just have an alias name and alias location but wouldn’t actually move or rename anything. It just would in xod ide. When you click on a node it could just have a field or two that shows you the real name of the node and it’s library. That way things would update as normal, other people could import and not have to worry about anything.
One of the biggest issues with the program it really requires you to have knowledge of electronic gates and the naming convention for them. I know electronics but hated the theory and math. So having something named concat instead of add-string or modulo instead of divide. There should be a common name version of the text.
I have gotten a pretty good handle on how this program works and I am getting the hang of it. If it wasn’t for Cesars I would have left. After 3 days of beating my head against the wall trying to figure out how this program worked. Cesars example of my project gave me a real world example of what I needed to figure it out how the program worked. I have watched nearly all of the videos on youtube and none were very helpful. This is for one main reason they didn’t explain WHY they picked this or that. They just said I am using this node… why… The built in help wasn’t useful either. The very first thing should be a theory of operation because this program is different from all others. I wasted a bunch of time looking for an arduino uno node not knowing that i didn’t need it, why because there wasn’t anything that said I didn’t need it and every other arduino programmer has one. Lesson one should be how you are different, theory of operations. The first lesson meant absolutely nothing to me because there was no real world reference for using it.
The bits lessons are not very helpful because there is nothing that really explains why… I would pick this vs that and relate it to several real world parts. It needs to say what info I need to have about that part, what things to think about, in order to make my digital part.
I am taking this time to tell you this because having used this program and getting a better understanding of it, I see just how great it is. I really believe it is far better than all of the others but it has some things really holding it back from wide adoption.
That’s an interesting point, thank you. Looks like a structure that might be made over the existing one. That is a new sidebar which is somewhat similar to the Project Browser (the Drawer?) but allows arranging the favorite nodes in folders by hand.
Praise @cesars! 
I feel that’s very important but, to be honest, I don’t quite understand what do you recommend for the introductory videos and articles? Seriously, I’m trying to get the idea and not sure whether I interpret it correctly.
Are you suggesting to start with a comparison to other programming systems (C++, Scratch?). In this case, does it make sense for newcomers who have no programming background at all?
Or are you talking about drawing a clear parallel between the virtual XOD nodes and real-world chips which might exist, but now are emulated?
Thank you for sharing your mind!
No No definitely not. Basically there was nothing in the beginning lessons that told me an overview of the software and on a basic level how things would work. Telling people with this program you won’t be bringing in an uno or mega and attaching different objects to the pins. Then explain what each of the basic xod folders contain and what they are for, but explain it as if you were talking to your dad. Compare it to something like a robot or whatever. You need something tangible that people can wrap their arms around. When I teach older people about how to build computers and explain parts and functions of each of the computer parts. First I compare to the human mind ram is short term memory and your HD is long term, then I compare ram to your work desk. Each program you run is a piece of paper on that desk. Some programs/ papers are much bigger than others. The bigger the desk, the more programs/papers you can put on it. Simple terms people can understand. When you go to start giving lessons about a particular folder you need to give an overview of what they are and their basic functions. You have to teach this like you were teaching your dad or at least a somewhat educated friend… lol
The problem with using electronic gates as a reference is that very few people know what they are. I get why it was done but if your goal is to get everyone to use xod then you have to have a simple language version of xod. I have been doing simple electronics for 20 years and I can’t remember what concat, boolean, delta, nor, nand does… how is a 13 year old who is interested in this going to figure this out… you know?
Ohh and parts being made need to have what it basically is before the number. Just posting a w5500 means nothing without me having to go look it up. It should say Ethernet - w5500 so you can glance and know what it is.
There is certainly some value in having all the wrenches in one drawer, but in this case, wrenches from different manufactures might have the exact same name, but function differently (especially when you get to higher-level functions). There is also value in knowing the manufacturer. If there is a XOD builtin that does what you need, there is no reason to use the off-brand copy that is more likely to break.
Why clutter your main drawers with tools you never use? The library system was never intended to download the entire library & see if there is something you might be able to use someday. It is intended as a resource to search if what you want is not builtin before you run off to build it yourself. There might be 3 implementations for a single device or function. If you don’t know what you might do with it, it will be hard to determine which is more appropriate, but you are not likely to need/want all 3. It doesn’t make much sense to download what is available now in case you might need it in the future, since what you need in the future might get added after you do the downloads (or there may just be an update for what you downloaded that will avoid a lot of aggravation trying to get it working).
Did you go through the built-in tutorial showing basic nodes and how they work together? It creates working patches that you can upload to your Arduino without any additional packages. It seems odd that someone would complain that instructions didn’t include what you don’t need to do…
BTW: modulo and divide are two different things (modulo returning only the remainder of a divide operation). I have never seen a programming language that used add-string instead of concat, but if you search for “add string”, it finds concat because both those words are in the description.
The built-in nodes give you easy access to low-level resources of Arduinos. You need to have some knowledge of gates/ports/etc. to use them. They are able to hide some details (like initializing input/output pins), but you reduce their usefulness if you abstract out too much. There are some wrapper nodes for specific functionality that is able to hide some of the options/complexities of the low-level nodes. Many libraries are able to abstract out all of the details and just provide a specific high-level function, but you are likely to need at least some low-level nodes to tie everything together.
The introductory tutorial gives you the basic building blocks and and getting started with XOD, then lets you use your imagination of how the parts might be used together. The best way to get started is probably to make small modifications to the examples and combine some together. Jumping straight to “this is what I want to do” is probably going to be too much to get started with, especially if you have never done any programming.
If you want an example of trying to explain why things were done the way they were, you can take a look at gweimer/traffic-light-advanced which tries to explain how pulses can be used to control program flow (and throws in some ideas about encapsulating functionality into a node), but any attempt to explain why is going to be a balancing act between being condescending about stating the obvious and taking someone on a torturous ride through your own thought processes… (My tutorial probably errors on the side of torturous ride…). It also assumes you have been through the basic tutorials and have a general understanding of XOD and tries not to dwell on the obvious (and probably misses some things that are not all that obvious; especially for beginners).
Unfortunately, almost all of the early contributors generating libraries and tutorials are going to be people with programming experience. It can be difficult for us to pull back from all that experience and speak to “normal” people. We do our best to answer questions when they come up.
Unfortunately, not everyone is going to be able to program, no matter how simple we make it. That is not an insult…some people just think/work differently. Computers have a tendency to do EXACTLY what you tell them to do, instead of what you meant them to do (hence the joke about the programmer who died in the shower. The shampoo said lather, rinse, repeat…there is no stop condition so he kept repeating). The creativity and impulsiveness that makes someone a great artist is going to work against them sitting down and systematically breaking a final goal into small tasks that can be easily programmed. Some outgoing people persons who are great at working with and motivating others are not going to want to sit down at a computer and drag icons around and link them together with wires. Something like XOD brings programming within reach of a lot of people who could never program in C++, but it is not going to work for everyone. I do NOT say this to suggest you should not be programming, just pointing out that there is a whole spectrum of people XOD is trying to reach. It is pretty much impossible to reach them all in a single tutorial. Maybe we need to focus more on trying to write a few non-programmer tutorials to help get newbies started, but that is very hard to do when you have no idea where they are coming from. There will be some who will never get it, some who will need one-on-one help to get started, some who just need a little more than what is provided to get jump-started, and some who feel what we have is all that is needed.
Maybe I don’t need to download everything but part of that was trying to figure things out. I was looking for parts that I didn’t need because nothing had told me that digital-read could count for most all standard parts… and that is my point. This program by far is the best of the others.
I thought the whole point of this program was to help people WHO DON’T KNOW CODE… because if I knew code… I wouldn’t need the program or at least I wouldn’t have looked for it. I am not talking about wide spread changes here. I am just talking about the ability to rename and reorganize files as I see fit, as every other program is in the world… If you can do that then importing and exporting those aliases shouldn’t be too difficult to do, so having simple names isn’t an issue. You just give people the option to download the file. The other thing is a different approach to training or at least adding a couple of things.
Ask yourself who was this program written for or who is the intended audience? Is it for programmers and electronic engineers? or is it for the average person who has an interest in learning arduino or both. I am not saying to turn it into a kids program, but making it more user friendly and easier to learn. I would make the videos myself but I am short on time and I don’t know enough about the program. I see how awesome this program is and with a slightly different approach, I think it could be huge. I guess the only thing you can do is try and get some figures on arduino users like age, location, depth of knowledge, ect. Then see if what your doing matches that core audience. Maybe I am in the minority and most arduino users know electronic gates, if so go with that. All I am saying is know your audience or the audience you want.
Hearing your perspective is definitely helpful. It may sound like I’m trying to negate your objections, but much of what I said was trying to explain that as programmers, there are certain things we just assume/know to be true, and it is hard to put ourselves in your shoes. Hearing your perspective and the problems you ran into getting started is very useful to help us improve our descriptions and how we try to do training…I just wish it was easier to actually implement a fix…
It sounds like we may need to start with a low-level overview of Arduino and how XOD ties into that. The trouble with relying on other Arduino introductions is that their examples will be using C++ code and be out of reach of many of the people we are trying to reach. I’m kind of thinking of a newbie section at the beginning of the XOD documentation that would link off to several smaller articles that start with very basic things that anyone with any Arduino could skip like analog/digital pins (and pointing out explicitly that any device nodes are just building on digital/analog-read/write). Another article could have basic programming like pointing out how if/else is just like English and showing how gate/select/etc. are extensions on that idea.
I think we should also have an article on the two “modes” in which XOD can be used (and standardize on the naming of them). I’m not even sure what to call them…one “mode” is “all at once”, a line-following robot might use this – as soon as a sensor finds/looses a line, it changes motor state; there is no program flow control. The other “mode” uses pulses to control program flow, an obstacle-avoidance robot that looks around to find its way out of corners will probably use this – certain steps need to be done in order. Generally speaking, a program should use one mode or the other. There are exceptions, but combining both modes will generally get you in trouble. Following the pulses for program flow control more closely resembles “normal” programming. We should probably also mention that starting multiple pulses in a single program is likely to be a problem (don’t use a clock or continuously node to “start” your program & generally avoid splitting the pulse) and loosing the pulse (like not handling error pulse from the ultrasonic node) will cause your program to freeze/end.
Everyone is born with talents one of mine just happens to be explaining complicated things in way that everyone can understand or at least wrap their head around. There needs to be a visual component to your explanation that people can picture in their head. It needs to be very simple. So explaining gates, you could use a relay race with stops or buildings. The AND building waits for the true runners to come in from building A and Building B before they will send on their own true runner on to the next stop. Whatever… something simple people can picture. Then show a very simple real life version of that gate working using arduino shields. Like an led and 2 push buttons. The led won’t light up until both buttons are pressed, ect. Then you can say the 2 buttons could be sensors instead and your don’t want the led to light until both sensors detect something. You get the idea.
Later on when explaining more complicated things, make sure you say WHY you chose this one vs that one. Especially when talking about making your own modules with bits. Like the button, why is not and debounce in there, what can happen if they are not.
I would describe gates more like behaviors on how you want something to act or choices you want it to make. I dunno, just free flowing.